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ABSTRACT 
The  technique  of  formal  abstraction  provides  an 
appropriate  tool  for  specifying  &r\  interface  between  layers 
of  computer  hardware  and  software.  An  abstract  machine  called 
AM  has  been  built  to  address  the  problem  of  portability  and 
reusability  of  software.  This  thesis  is  the  design  and 
implementation  of  a  "C"  compiler  for  this  abstract  machine. 
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I.  INTRODUCTION 

In  today's  computer  world,  portability  is  a  well-known 
problem  which  arises  in  a  variety  of  situations.  Since 
computer  software  evolves  in  connection  with  a  particular 
hardware  environment,  and  often  assumes  features  closely 
related  to  characteristics  of  its  own  hardware,  this  problem 
has  been  unavoidable. 

Formalizing  the  relationship  between  hardware  and 
software  resources  was  treated  is  a  previous  NPS  thesis  by 
Yurchak  CRef.  13,  whose  efforts  resulted  in  the  specification 
and  implementation  of  a.ri    abstract  machine,  called  AM. 

The  abstraction  of  a  bit  mapped  display  resource  was 
added  to  AM  in  another  NPS  thesis  by  Hunter.   CRef.  £.'] 

Finally,  art  abstraction  of  a  formally  specified  reusable 
database  was  added  to  the  same  machine  by  Zang.   CRef.  31 

This  presentation  is  a  further  extension  of  the  work 
started  by  Yurchak  and  Hunter:  fin  abstract  computer  and  its 
programming  environment.  Its  major  objective  is  a  compiler 
for  a  subset  of  the  C  language  for  AM. 

A.  THE  PORTABILITY  PROBLEM 

It  is  well-known  that  moving  large  programs  from  one 
machine  to  another  is  frustrating  work.  And  it  is  also  known 
that  once  the  software  has  been  moved  to  the  new  machine,  it 
is   not   predictable  whether  or  not  it  will  work   as   before. 


6 


Even  if  it  seems  to  work,    it  may  consume  more  resources  than 
expected. 

For   a   couple   of  reasons,   the  portability   problem   is 
getting  worse,  not  better: 

—  Computer   architectures    have  been  changed  to  make   them 
look  like  what  the  programmer  wants 

—  The    number    of    the   devices    included    in    modern 
architectures  has  been  maximized 

—  Both  languages  and  machines  a.r<s    related  to  the  data   they 
manipulate  in  an    implementation  dependent  way 

These   and  other  factors  make  the  portability   problem   a 

difficult   task,   and   in  addition,   they  affect   some   other 

difficult    issues    like    language   design    and    software 

eng  ineer ing. 

B.  CURRENT  IMPLEMENTATIONS  TO  SOLVE  PORTABILITY  PROBLEM 

The  usage  of  high  level  languages  provides  a  degree  of 
high  level  abstraction,  and  provides  some  measure  of  software 
standardization  and  portability.  But  the  portability  of  high 
level  languages  is  limited,  since  all  the  layers  of  software 
below  this  high  level  have  to  be  moved,  in  order  to  port  such 
a  system. 

There  a.x^e  other  abstraction  levels  between  the  computer 
hardware  and  the  application  environments.  Especially 
operating  systems  represent  a  software  abstraction  of 
physical  resources,  and  support  the  layers  of  software  built 
over  this  level.  Starting  with  CP/M  and  UNIX,  we  have  seen 
some   good   implementations    that  provide  such  a.r\       abstract 


level  to  some  degree.  The  main  idea  of  the  AM  machine  is  to 
abstract  and  formally  define  other  physical  resources  found 
in  typical  computing  systems. 
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II.  ABSTRACT  MACHINE,  AM 

The  Abstract  Machine  (AM)  is  a  result  of  Yurchak  CRef.  12 
and  Hunter's  CRef.  £3  efforts  to  solve  the  problem  of 
formalizing  the  relationship  between  hardware  and  software 
resources.  It  is  implemented  as  a  finite  state  machine 
interpreter,  with  ari  assembler.  Details  of  the  newest  version 
of  the  AM  assembler  can  be  found  in  Zang' s  CRef.  31     thesis. 

"Abstraction"  describes  the  separation  of  the  defining 
properties  of  an  object  from  other,  unnecessary  details  about 
it.  A  programmer  is  primarily  concerned  with  solving  a 
problem.  Appropriately,  the  tools  at  his  disposal,  such  as 
programming  languages,  development  aids,  and  the  programming 
environment,  form  a  problem  solving  abstraction.  The  hardware 
(and  some  of  the  software)  on  which  this  problem  solving 
abstraction  is  implemented,  however,  is  an  abstraction  of  a 
different  sort. 

The  fuzzy  area  between  software  and  physical  resource 
abstractions,  sometimes  simpl ist ical ly  perceived  as  the 
boundary  between  hardware  and  software,  exposes  a  number  of 
shortcomings  in  language  design  and  computer  architecture 
collectively  termed  the  "semantic  gap". 

Narrowing  the  semantic  gap  requires  significant  changes 
in  the  fundamentals  of  computer  architecture  and  language 
design.  Three  major  factors  which  significantly  contribute  to 
this  problem  are: 


-  Informally  descr i bed  - semant ics ; 

-  Representation  dependent  data  types; 

-  Arbitrarily  designed  instruction  set  architectures. 

The  AM  was  designed  to  fill  this  semantic  gap  by 
addressing  the  above  problems.   CRef.  13. 

In  the  AM  implementation,  a  text  file  representing  an 
assembly  language  program  is  translated  by  the  assembler  into 
a  relocatable  object  module.  A  loader,  part  of  the  AM 
interpreter,  loads  this  object  module  into  the  appropriate 
cells,  and  AM  executes  it. 

The  following  presentation  is  an  implementation  _  of  a 
subset  of  the  high  level  language  "C",  for  that  abstract 
machine.  It  is  a  compiler  which  compiles  C  source  code  and 
generates  assembler  source  code  for  the  AM. 
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III.  DISCUSSION  OF  "C"  SUBSET 

Since  commercially  good  compilers  are  very  large  programs 
and  it  takes  on  the  average  six  man— years  to  write  one  of 
them,  this  research  work  had  to  be  a  small  subset  of  the  C 
language. 

The  goal  was  to  write  a  small  portion  of  C  in  the  C 
language  itself,  and  then  by  feeding  the  output  of  this  work 
into  itself,  to  create  a  native  code  C  compiler. 

Since  this  work  was  going  to  be  a  v^ace    against  time,   the 
subset  had  to  be  as  small  as  possible,  but  on  the  other  side, 
had   to  be  large  enough  to  be  able  to  compile  its  own   source 
code. 

The  sub-goal  was  to  use  a  strictly  limited  number  of 
features  to  write  the  compiler,  because  any  new  feature  used 
in  the  code  would  require  implementation  of  the  same  feature 
in  the  compiler. 

The  outcome  of  this  work  was  not  sophisticated  enough  to 
compile  itself.  It  evolved  as  a  small  subset  of  the  C 
programming  language,  so  called  "Tiny-C".  find  since  it  was 
not  sufficient  to  compile  its  own  code,  it  is  used  as  a 
cross-compiler  from  host  MS-DOS  computers  to  the  target 
mach  i  ne  ftM. 

ft.  TINY-C  SUBSET 

Tiny-C  is  a  small  subset  of  C,  and  a  thesis  project 
more  than  a  language.  There  are  many  features  which  a  real 
programming  language  has  to  have,  but  Tiny-C  does  not. 
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The  Tiny-C  compiler  was  written  in  five  months  and  is 
considered  to  have  the  fundamental  structure  of  a  real 
compiler.  Hopefully  it  will  be  modified  and  improved  in  the 
future,  and  may  be  usable  for  real  applications. 

Appendix  A  is  a  listing  of  the  Tiny-C  language  grammar. 
But  this  grammar  is  obviously  not  the  complete  "C" 
language.   At  least: 

-  Structure  and  union  specifiers  are    not  included. 

-  Functions  are  not  allowed  to  return  addresses. 

-  Assignments   inside   the  expressions  are    not    allowed, 
because     they   were   considered   as    making    programs 
"unreadable".  For  instance: 

"if  (  <.jo«-  Jimrny+5)  >  5  )"  is  not  allowed  in  Tiny-C. 

-  Multiple   assignments  are   not  implemented.  For  instance: 
"jo«»   Jimmy   "IS  *  m*ry|"  is  an       invalid   statement   in 

Tiny-C. 

B.  THE  TINY-C  COMPILER 

Even  though  the  Tiny— C  language  subset  was  planned  within 
the  limits  in  this  thesis,  the  Tiny-C  compiler  can  only 
compile  and  generate  code  for  ar\  even  smaller  subset  of  the 
above  grammar. 

The   Tiny-C  compiler  implementation  car\    parse   the   whole 
Tiny-C   subset   and  give  proper  error  messages  if   necassary. 
But, 

-  due  to  the  time  constraints,  and 

-  due   to   the   restricted  capabilities  of   the   target   AM 
mach  ine 


1£ 


the  Tiny-C  compiler  cannot  generate  code  for  the  whole  Tiny— C 
language. 

In  the  Tiny-C  compiler ; 

—  Floating  point  arithmetic  is  not  implemented.  Because  it 
is  not  supported  by  AM. 

-  Bitwise  and  shift  expressions  are  not  implemented,  since 
they  are    not  supported  by  AM. 

—  Since  AM  has  strictly  defined  data  types  and  does  not 
allow  type  conversions,  address,  pointer  and  array  types 
are    not  implemented. 

-  Since  AM  is  designed  as  ari  operating  system  independent 
software  machine,  the  "ttinclude"  preprecessor  is  not 
implemented. 

—  Since  AM  does  not  have  a  linker  yet,  external 
declarations  are  not  implemented. 

-  Auto,  static,  register,  boolean  types  are  not 
implemented. 
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IV.  THE  DESIGN 

This  chapter  describes  the  Tiny-C  compiler  step  by  step. 
But  obviously  the  purpose  of  this  presentation  is  not  to 
teach  the  "compiler  writing  art",  or  to  explain  the  target 
Abstract  Machine's  assembler.  Complete  documentation  for  the 
AM  Assembler  car)  be  found  in  Yurchak'  s  thesis  CRef.  1 J  .  For  a 
better  understanding  of  the  following  structures,  Ullrnann's 
"Compilers,  Techniques  and  Tools"  CRef.  4]  is  recommended  as 
a  background  reference  for  compiler  writing. 

The  Tiny-C  Compiler  is  written  in  nine  steps.  These  are: 

-  Scanner  or  Lexical  Analyzer 

-  Grammar 

-  Recursive  Descent  Parser  with  Backtracking 

-  Data  Structures  for  the  Parser 

-  Error  Cheeking  and  Error  Messages 

-  Emission  of  Intermediate  Code 

-  Intermediate  Code  Optimization 

-  Data  Structures  for  the  Code  Generator 

-  Target  Code  Generation 

We  will  first  go  through  these  steps  briefly  in  order  to 
get  acquainted  with  the  architecture  of  the  Tiny-C  compiler. 

A.  SCANNER  AND  LEXICAL  ANALYZER 

In  general,  scanners  and  lexical  analyzers  are  language 
independent  structures.  The  same  scanner  may  be  used  for  a 
couple   of   different   compilers.   For  this   reason   we   will 
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introduce   this   structure  even  before  discussing  the   Tiny— C 
grammar. 

Contrary  to  the  header  of  this  section,  Tiny-C  does  not 
have  a  scanner  or  lexical  analyzer  in  the  classical  sense. 

Even  though  the  most  common  way  of  writing  compilers  is 
analyzing  the  input  data  stream  lexically,  and  after 
tokenizing,  passing  tokens  to  the  parser  as  they  arG  needed, 
this  was  not  the  way  scanning  was  implemented  in  this 
compiler.  The  Tiny-C  scanner  is  made  up  of  a  couple  of 
routines  used  by  a  recursive  descent  parser  with  a 
backtracking  tool.   There  is  no  tokenized  data  stream. 

The  idea  is  to  read  the  input  stream  into  a  scanner 
buffer,  (which  is  implemented  as  a  ring  buffer)  and  parse 
it  there.  This  technique  gives  ari  ability  to  backtrack  and 
makes  it  possible  to  write  a  very  simple  recursive  descent 
top— down  parser.  Uith  such  a  backtracking  tool,  the  grammar 
does  not  need  to  be  massaged  to  a  fully  LL ( 1 )  grammar,  that 
is  even  if  it  is  ambiguous  in  the  LL ( 1 )  sense.  In  any 
ambiguous  case,  the  parser  car\  try  all  possible  options  by 
bact racking. 

Let's  start  by  introducing  our  scanner  buffer 
and  its  initialization. 


init_buf<)       /*   initialize  scanner  buffer        */ 
■C 

Reads   input  source  file  into  scanner   buffer.   Sets   the 
pointers   for  the  current  place  (for  initializing   procedure, 
it   is  simply  the  begining  of  the  scanner  buffer)  and  for  the 
very  last  character  in  the  scanner  buffer. 
> 


The  scanner  may  or  may  not  read  the  whole  input  stream 
at  ortce^  because  its  ring  buffer  has  a  limited  size.  Now  the 
next  question  is  how  to  get  a  character  from  this  buffer 
(since  tokens  are  not  used,  we  have  to  deal  with 
characters),  and  if  it  is  the  end  of  the  characters,  how  to 
read  some  more  input  into  this  ring  buffer. 

char     gatchrO     /*  get  character  routine     •*/ 
■C 

Gets  the  next  character  from  <sca.rtr\Bt^    buffer,    and   loads 
it   into  global   "nextch".     If  it  reaches  the  current  end  of 
the  scanner  buffer,    it  reads  some  more  text  from  the   source 
into   scanner  buffer.    If  it  meets  the  end  of  file  character, 
it  sets   the   "file_end"  flag  TRUE. 
> 

We   even  C3.r\    put  a  character  back  into  the   buffer,     if 

needed. 


ungetchrO        /*  un— get  character  */ 

Puts  a  given  character  back,  into  scanner  buffer. 
> 


After  initializing  the  scanner  buffer,  we  ca.ri  get  as 
many  characters  from  there  as  we  want  to.  But  parsers  &r<2 
higher  level  concepts,  and  they  shouldn't  deal  with  the  low 
level  structures  of  scanning  like  getting  three  more 
characters  or  putting  back.  one.  Parsers  mostly  work  on 
tokens.  If  we  had  a  pure  tokenized  implementation,  we  could 
simply  pop  a  token  number  from  the  sc aririet^  buffer.  But  here 
we  need  something  to  give  tokens  to  the  parser.  Also  white 
characters  and  comments  should  be  ignored. 
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String   tokens   are  given  to  the  parser  by  the   following 
rout  ine. 

matchtoken (str, whtchk)      /*  match  to  a  given  string  token  */ 
char     str[],  /*  string  token  */ 

whtchk;    /*  boolean  variable  for  white  chr.  check  */ 
■C 

This  routine  at temps  to  read  the  string  token  from 
scanner  buffer.  A  following  white  character  or  delimiter  is 
optional,  and  this  decision  is  made  by  the  caller,  namely 
parser.  It  returns  TRUE,  if  the  token  matches  (and  a  white 
character,  optionally),  else  returns  FALSE.  In  case  of 
FALSE,  it  backtracks  in  the  scanner  buffer  to  its  previous 
pi  ace. 
> 

The   following  routine  attempts   to   match   a  single  cha- 
racter in   the  scanner   buffer   and  returns  a  boolean  result. 


match  (chr)        /*  match  to  a  single  character   •*/ 
char     chr;     /*  character  to  match  ■*/ 

■C 

delwht  ()  ; 

/*  if  character  matches,  return  TRUE     •*/ 
if  (nextch==chr ) 
-C 

next ch  =  get chr ( )  ; 
return (TRUE) ; 
> 

ret  urn (FALSE)  ; 
> 


Both  of  these  routines  delete  white  characters  first. 
And  m  case  of  FALSE,  they  do  not  backtrack  to  their 
previous  places  exactly,  otherwise  the  following  routines 
have  to  skip  white  characters  one  more  time.  So,  in  the  case 
of  the  FALSE  or  "unmatched"  case,  they  backtrack  to  the  very 
first   character  which  comes  just  after  the  white  ones. 
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delwhtO     /*  delete  white  characters       */ 

< 

Used  by  both  match-character  and  match-token  routines  and 
skips   all   the   following   white   characters   (blank,    tab, 
carriage  return  and  line  feed  characters)  and  the  comments  in 
the  scanner  buffer. 
> 

B.  GRAMMAR 

Since  there  is  not  a  standard  C  language  grammar,  we  had 
to  first  write  a  grammar  to  parse.  The  Tiny— C  subset  was 
discussed  in  the  previous  chapter,  and  its  complete  grammar 
is  presented  in  Appendix  A. 

In  this  grammar  (Appendix  A),  any  terminal  or  non- 
terminal followed  by  a  '  ■*'  character  means  "none  or  more,  " 
followed  by  a  "+"  character  means  "one  or  more, "  and 
followed  by  a  "?"  character  means  "optional"  or  "none  or 
one. "   Under  these  definitions   for  example: 

program: 

<pre-precessor> *  <data-def init ion> *  <f unct ion-def init ion) + 

The   non-terminal  (program)  goes   to  any  number  of   (pre- 

precessor) ,   followed  by  any  number  of  (data-definition)   and 

followed   by   one   or  more    (f unct ion— def init ion) . 

The  ' I'  character  means  "or".  For  example: 

pre-preceffisor  s 

"#define"    <f i le-def init ion>   I 
"#include"   <f i le-def init ion) 

Thus,    (pre-precessor)  goes    to   "#define"    followed 

by  (file-definition),  or,  "# include"  followed  by  (fi le- 
def  init ion) . 

The  ' !'  character  means  "allowed  at  most  once. "  For 
example : 
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switch-statement : 

"switch"       "("        (arithmetic-expression)        " ) "       "<" 
<case-stmt > +      ">" 

case- stmt : 

"case"  I  "default"!   (constant-expression)   ":" 
(statement > * 

Thus,    (switch-statement)   can   go  to  "default"   at   most 

once. 

C.  PARSER 

A  very  simple  form  of  a  working  parser  is  presented  in 
Appendix  B.  It  is  a  recursive  descent  parser  but  with  a 
backtracking  feature.  There  is  a  one-to-one  correspondence 
between  non— terminal  names  in  the  grammar  and  function 
names  in  the  parser.  The  reader  is  encouraged  to  read  the 
parser  with  ^ri  eye  on  the  grammar.  With  the  grammar's  help, 
it  is  not  difficult  to  understand  the  structure  of  the 
parser. 

In  this  first  version  of  the  Tiny~C  parser,  all 
functions  backtrack  if  they  fail.  In  the  real  Tiny— C 
environment  this  is  extremely  unnecessary,  because  in 
the  Tiny-C  grammar,  ambiguity  exists  in  a  few  places  only. 
The  reason  this  first  version  is  presented  in  Appendix  B  is 
its  clarity  and  simplicity.  In  the  following  versions, 
unnecessary  backtracks  have  been  taken  out. 

In  all  the  routines  in  the  parser,  there  Are  two 
backtracking  tools.  First,  the  "oldp"  old  pointer  points  to 
the  parser's  previous  place  in  the  scanner  buffer,  and 
second,   the  "line_no"  line  number  keeps  track  of  the  current 
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line  number  for  e^ror    checking  purposes.  If  a  function  fails, 
these   routines  backtrack  to  their  previous  states  and  try  to 
find  another  legal  path  to  parse. 

Appendix  C  has  the  routines  for  the  basic  nonterminals 
and  terminals  of  the  Tiny-C  parser.  So,  it  presents  a 
working  version  of  that  parser  with  Appendix  B. 

D.  DATA  STRUCTURES  FOR  THE  PARSER 

Now  is  the  time  to  introduce  some  data  structures  to 
improve  the  Tiny-C  parser.  The  first  one  is  going  to  be  a 
name  string  structure  since  all  the  following  tables  need 
this  structure. 

1 .    Name  String  Implementation 

A   name  string  is  basically  a  big  character  array  (or 
a  string)  which  holds  all  the  names  used  in  the  source   file. 
Tiny-C  has  two  routines  to  implement  this  structure: 

The  first  one  is  used  to  add  a  new  name  into  the  name 
string,  and  the  second  one  is  used  to  look,  for  a  given  name. 


«dd_nam» < >        /*  add  a  name  into  the  name  string   */ 
-C 

Adds  a  new  name  into  the  name  string  from  the 
"id_name"  global  variable.  The  "id_narne"  variable  holds  the 
current  identifier  name  all  the  time.  The  function 
"identifier"  in  the  parser  sets  this  variable  whenever  it 
parses  a.r\  identifier. 
> 


f  ind_name  < )  /*  find  a  name  in  the  name  string       ■*•/ 

■C 

Looks  for  "id_name"  in  the  name  string.     If   found,     it 
loads   the   identifier's  address   into  a  pointer  and   returns 
TRUE,   else  returns  FALSE. 
> 
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In  the  current  version  of  Tiny— C,  the  name  string  was 
implemented  completely  sequentially.  Instead,  there  could 
have  been  a  hashing  mechanism,  which  would  be  much  more 
efficient.  When  testing  the  whole  compiler,  it  was  observed 
that  a  large  number  of  predefined  constant  names  and 
variables  was  making  execution  slow. 

2.   Constant  Table 

Constants  a^o  implicitly  declared  elements.  In 
the  Tiny-C  compiler,  a  constant  table  is  implemented  to  take 
care  of  them.  Since  every  occurence  of  a  constant  denotes 
the  same  declaration,  we  do  not  need  to  check  if  a  constant 
occurs  more  than  once.  We  simply  add  each  constant  into  the 
constant  table  as  it  occurs. 

*dd_nurn  (  )    /*  add  a.rt    integer  number  into  constant  table  */ 
■C 

Adds  art  integer  numeric  value  into  the  constant  table 
if  it  is  not  in  there.  find  returns  its  address  in  a 
poi  nt er. 

> 

In  the  current  version  of  AM,  integers  Bre  the  only 
numeric  type.  So  it  is  the  only  numeric  type  inplemented  in 
Tiny-C,  and  is  the  only  constant  denotation  required. 

Since  input  data  is  a.rt  integer  for  the  above  routine, 
and  since  source  file  is  read  as  character  stream  from  the 
scanner  buffer,  we  need  a  string— to— numeric  conversion 
routine,  to  corw&rt    text  input  into  numeric  values. 
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str_num<)        /*  string  to  numeric      */ 
-C 

Takes    a    string   "num_name"   (numeric  name)   which   is 
set   by   the  "constant ()"  routine   in  the  parser,   calculates 
its    numeric    value,    and   returns  it   in   the   "num_cnst" 
(numeric  constant)  global  as  Ari    integer. 
> 


3.   Definition  Table 

In  Tiny— C,  the  preprecessor  command  "ttdefine"  lets 
us  define  constant  identifiers.  So,  a  definition  table  is 
implemented  for  these  identifiers. 

In   case   of   a  "#define"  declaration,    we  need  to    add 
a   new  constant  identifier  into  the  definition  table. 

add_cnid<)  /*  add  constant  identifier       */ 

-C 

First,  checks  if  the  given  id-name  is  already  in  the 
definition  table.  If  so  it  gives  s^ri  error,  since  definition 
of  the  same  constant-id  more  than  once  is  nonsense.  Otherwise 
it  nadds  that  given  constant  identifier  into  the  definition 
table. 
> 

The   next   problem   in  implementing  constant   identifiers 

is    finding  the  corresponding  values  for  these  constant   id— 

narnes,  if  they  a.x^e    met  when  parsing  a  program. 


find_cnid<)  /*  find  constant  identifier  */ 

■C 

Takes     a  constant    identifier   name  and   looks   for  it 
in   the  definition  table.    If  found,     it  sets  a   pointer   to 
its   place  in  the  definition  table  and  returns  TRUE,   else  it 
returns  FALSE. 
> 


4.    Scoping  Rule 

In  classical  compilers,    symbol  tables  are  primarily 
responsible   for  establishing  the  scoping  rules.   The   Tiny-C 


compiler  solves  the  scoping  problem  in   a  different  way. 

Our  Tiny-C  compiler  has  a  variable  string  which  holds 
all  valid  variable  names  in  the  current  scope.  When  the 
parser  starts  parsing  a  new  function  or  a  new  compound 
statement,  (namely  a  new  "block"  in  block  structured  language 
literature),  the  parser  puts  a  mark  into  the  variable  string 
to  define  the  beginning  of  the  new  block,  and  adds  the 
following  variable  declarations  into  the  same  string. 
Whenever  the  parser  goes  out  of  a  block,  it  deletes  the 
very  last  block's  variables  from  this  string.  (Since  the 
Tiny-C  compiler  is  a  one-pass  compiler,  the  deletion  of  the 
variables  for  the  last  block  is  acceptable  in  this  case).  So, 
any  time  a  variable  is  usedr  the  compiler  looks  for  this 
variable  in  the  variable  string,  starting  from  the  end  to 
the  beginning.  If  found,  it  finds  a  pointer  to  the  symbol 
table  for  this  variable,  if  not,  it  gives  e^rt  error  message 
since  that  particular  variable  is  unknown  (or  out  of  scope?). 


find_var()       /*  find  a  variable  in  variable  string  •*/ 
{. 

Takes  ar>       id-name   and   looks  for  it   in    the   variable 
string.     If   found,     it  sets   a  pointer  to  the  symbol  table 
pointing   to  its  place  in  there   and   returns  TRUE,  otherwise 
it  returns  FALSE. 
> 


We   introduced   searching   for   variable   names   in    the 
variable  string  before   discussing  inserting  them.  The  reason 
is,   whenever   the  parser   meets  a  new  variable   declaration, 
it  is  supposed  to   add  that  new  variable  into  both  the  symbol 


table  and  the  variable  string.  In  the  Tiny-C  compiler,  one 
single  routine  does  both  these  duties.  Since  the  symbol 
table  is  not  introduced  yet,  we  didn't  meet  this  routine 
either. 

Here,  the  theory  to  satisfy  scoping  rule  is:  mark  the 
beginning  of  a  block  in  the  variable  string  when  starting 
to  parse  a  new  block,  and  delete  the  most  recent  block's 
variables  when  exiting  from  it.  So  any  variable  which  is  not 
in  the  variable  string  is  automatically  out  of  scope. 

5.   Symbol  Table 

In  the  Tiny-C  implementation,  the  symbol  table  is 
responsible  for  variables,  function  names,  label  names,  and 
function  arguments. 

Let's  first  start  with  how  to  add  a  new  variable  into 
the  symbol  table  when  a  variable  declaration  occurs. 


add_var()        /*  add  variable      #/ 
■C 

Gets  a  new  variable's  id_name  and  gets  its  type,  then  add! 
it  into  symbol  table  and  variable  string. 
> 


Similarly,  label  declarations  require  label  names  to 
be  added  into  the  symbol  table,  too.  But  we  shouldn' t 
add  labels  into  the  variable  string,  since  in  '  C  they  do 
not  satisfy  the  same  scoping  rules  as  variables. 


«dd_label < )      /*  add  a  label  into  symbol  table     */ 
-C 

Sets  a  label,  and  adds  it  to  the  end  of  the  symbol  table. 

> 
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Whenever  the  parser  meets  a  new  label  declaration,  it 
adds  this  label  into  the  symbol  table  by  the  above  routine. 
But  it  must  be  smart  enough  not  to  accept  duplicate  label 
declarat  ions. 

One  pointer  is  assigned  to  point  to  the  beginning  of  the 
very  last  function  in  the  symbol  table.  So,  when  the 
parser  meets  a  new  label  declaration,  it  first  starts  from 
the  beginning  of  the  last  function  in  the  symbol  table,  and 
goes  all  the  way  down  to  the  end  of  it,  to  look  for  a 
same  label  name.  If  it  finds  one,  it  gives  a  d implicated 
label  declaration  errcv,  since  the  same  label  is  not  allowed 
to  be  declared  twice  in  the  same  routine  in  this  language. 
The  following  routine  does  this  job  in  the  Tiny-C  compiler. 


dup_lbl()     /*  is  duplicate  label?      -*/ 
■C 

Checks  if  the  same  label  name  has  been  declared  before. 
> 


6.    Label  Table 

In  the  C  language,  any  label  referenced  by  a  goto 
statement  has  to  be  declared  somewhere  in  the  same  function. 
Classically,  compilers  read  the  source  file  twice.  But  the 
number  of  input/output  operations  is  very  important  for 
total  execution  speed.  Since  the  Tiny-C  compiler  is 
designed  as  a  "one-pass-compiler",  we  immediately  have 
this  problem:   detection  of  undeclared  labels. 

Classical   two  pass  compilers  read  all  label  declarations 
in  the  first  pass.   So,    in  the  second  pass  they  car\    check  if 


"goto  label"  statements  are  valid.  When  our  one-pass  Tiny-C 
compiler  meets  a  goto  statement,  and  if  the  referenced 
label  name  has  not  been  declared  yet,  it  is  unpredictable 
if  this  label  is  going  to  be  declared  in  the  following 
statements.  To  solve  this  problem,  Tiny-C  implements  a 
label  table,  and  at  the  end  of  every  function,  it 
checks  if  a  referenced  but  undeclared  label  exists. 

Whenever  a  label  is  referenced  by  a"  goto  statement, 
the  compiler  saves  it  in  the  label  table  by  the  following 
rout  i  ne. 


/•*  save  label  into  the  label  table  */ 


save_lbl ( ) 
■C 

Inserts    a   label   which   is   referenced   by   a 
statement  into  the  label  table  for  future  checking. 
> 


g  i_'  u  o 


find  at  the  end  of  every  function,  the  compiler 
checks  if  the  labels  referenced  by  goto' s  were  ever  declared 
in  the  function. 


/*  check,  labels 


*/ 


check_l Ab«lo ( ) 
< 

Called   by  the  parser  at  the  end  of  every  function  body. 
Checks   if   labels   in  the  label  table  are       declared   in   the 
symbol  table. 
> 


7.   Funct ion  Cal Is 

Tiny-C   keeps  function  names  and  their  argument  counts  in 
the  symbol   table.     In   case  of  a  function  call,     it  checks 
if   this  function  has  been  called  before,   and  if  it  has  not, 
enters   its  name   and   argument   count  into  the  symbol  table. 
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If    it    has    been  entered   before,     it   checks    if    the 

argument   count    in   the   new  function   call  is  the  same   as 

the  one  in  the  symbol   table.     If  the  argument   counts    s.r& 

not   the  same,     it  gives  a.r\       "inconsistent  argument   count" 

error. 

add_f  un  <  f  un_no)       /*  add  function  into  symbol  table    -*/ 

char     *fun_no; 

■C 

Adds  a  function  name  and  its  argument  count  into  the 
symbol  table  in  case  of  a  function  call,  and  if  it  is  the 
first  call  of  the  function.  If  it  is  not  the  first  call,  the 
function  is  already  in  the  symbol  table,  so,  it  checks  if 
argument  counts  match.  In  both  cases,  it  returns  the 
function's  function  number  (basically  symbol  table  entry 
number)  to  the  parser,  to  emit  intermediate  code. 
> 

8.   Function  Declarations 

In  the  C  language,    parameter  declarations  follow   a 
function   declaration.    Parameter   names   have  to   be   given 
inside   parentheses  immediately  following   a   function   name, 
and  then  they   have   to   be  declared  one  more  time  with  their 
types. 

The  following  parameter  declarations  have  to  match  the 
ones  given  with  function  name.  Tiny-C  has  two  routines  to 
get  this  mechanism  to  work  properly. 


chk^prmt ( )       /*  check  parameter   ■*/ 
■C 

fit  the  end  of  a  parameter  declaration,  this  routine 
checks  if  that  parameter  was  given  as  one  of  the  function's 
arguments,  or  if  it  is  declared  more  than  once!  If 
everything  is  proper,  it  enters  the  parameters'  type  into  the 
symbol  table,  since  the  parameter  name  was  already  entered 
before  (when  parsing  the  parameter  list  following  the 
function  name). 
> 
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find,  at  the  end  of  all  parameter  declarations,  compiler 
has  to  make  sure  that  all  the  arguments  given  with 
function   name   were  declared  as  parameters. 


chk_parms <)      /*  check  all  the  parameters  */ 
■C 

When  parameter  declarations  are  done,  checks  if  there  is 
any  parameter  name  in  the  symbol  table,  without  its  type. 
Since  parameter  names  ax^is  entered  into  the  symbol  table  when 
parsing  the  parameter  list,  and  types  a.v<=  entered  in  ■  there 
when  parsing  the  following  parameter  declarations,  if  there 
is  any  parameter  with  its  type  missing,  that  means  it  is  not 
decl ared. 
> 


These  a.re    all   the  data  structures,  used  by  the  parser  to 
manage   variables,   constants,    labels,   function   names   and 
arguments,  and  all  remaining  structures  in  the  Tiny— C  parser. 
The  following  section  improves  the  parser  one  more  step,   and 
handles  the  error  checking  mechanism. 

E.  ERROR  CHECKING 

A  list  of  error  and  warning  messages  used  in  the  Tiny— C 
compiler  is  given  in  Appendix  D. 

Error    and    warning    messages    Are  given    by    the 

f o 1 1 ow i ng  rout  i nes : 


»rr_msg  (mffig_no)       /*  error  messages    *•/ 
char     msg_no; 
■C 

/-*  increment  error  counter  •*/ 

++err_cnt ; 

/■*  give  line  number  of  the  error     •*/ 
pr  i  nt  f  <  "  'Ad    error  !  "  ,  1  i  ne_no )  ; 
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/•*  and  give  the  error-    message         */ 

switch (msg_no) 

case  list  for  all  error  messages  described  in  Appendix  D. 
> 
> 


warning  <rnsg_no>  /*    warning    messages    */ 

char  msg_no; 

■C 

/*  give  line  number  of  the  warning     */ 
printf("*/-d  warning!  ",line_no); 

/*  give  the  message  -*/ 

switch  (rnsg_no) 

-C 

case  list  for  all  warning  messages  described  in  Appendix  D. 

> 
> 


F.   INTERMEDIATE  CODE  GENERATION 

In  order  to  generate  code  for  the  target  machine,  first 
the  compiler  has  to  build  a  parse  tree.  Appendix  E  is  a 
list  of  nodes  that  form  Tiny— C  parse  trees. 

Now,  the  same  old  heavy-duty  parser  can  shoulder  one  more 
Job:  emissions  of  intermediate  code. 

The  following  routine  does  the  intermediate  code 
emissions,  when  called  by  the  parser.  It  takes  two  arguments; 
the  node  itself,  and  the  number  of  the  children  of  this  node. 
If  there  is  not  any  error  up  to  that  time,  the  parser  emits 
the  code  into  s.r\  emission  table,  (which  is  in  fact  a 
flattened  parse  tree)  and  increments  the  em i t -count er. 


•mi  t  (node,  ch  i  Id )     /*  emit  intermediate  code  •*/ 

char     node,         /■*  node  kind  to  emit  */ 

child;   /*  #  of  the  children  belonging  to  this  node*/ 
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■c 

/*  if  there  is  not  any  error,  give  emissions     */ 

if  ( ! err_cnt  ) 
-C 

emitstr  [emit _cnt  1     =    node; 

em  i  tch  1  Cernit  _cnt  ]     =    child; 

++emi t _cnt ; 
> 


G.  POSTPONED  EMISSIONS 

There'  are    times  when  we  do  not  want  to  emit  code  in   the 
same   order   as  we  parse.   fin  assignment  statement  is  a   good 
example  for  this  situation. 
Suppose  we  have  the  assignment: 

jo©  ■  jimmy  *  5; 
The  parse  tree  for  this  statement  is: 

assi  gnment 

variable  multiplication 

joe  variable         constant 

j  i  mmy  5 

Since   our  parse  tree  is  in  flattened  form,  the  order  of 

the   intermediate  code  emissions  for  the  above  tree,   should 

be: 

jimmy,   variable,  5,  constant,  multiplication,  joe,  variable, 
assignment 

But   this  is  not  the  same  order  we  parse!   There   may   be 

some   quick   solutions  for  this  particular  problem.   But   the 
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case   might   be   worse   than   the   above   one.   Consider   the 
following  statement: 

joaZ     <  j  immy*15)  "/.  mary++  1    ■  joeCSD; 

Here,  the  left  value  is  not  a  simple  variable.  It  is  a.r< 
a.v^&y    element  with  a  complex  index  expression. 

Summarizing,   there  are  cases,  when  we  simply  do  not  want 
to  give  emissions  immediately.  Ule  want  to  save  them,  and  then 
at  the  end  of  some  certain  expressions  we  want  to  emit   them. 
This  type  of  emission  is  called  "postponed  emission." 

Up   to   now,    our   recursive   descent   parser   has   been 
suffering  the  same  problem.   But  for  the  sake  of   simplicity, 
we   ignored  it.   Now  is  the  time  to  build  some  mechanisms   to 
make  the  parser  be  able  to  postpone  emissions. 

First  of  all,  we  have  to  make  our  emission  tool  more 
flexible.  The  following  is  revised  version  of  our  "em it -code" 
f '.met  ion. 


emit (node, chi Id) 

mt      node, 

chi Id; 
■C 
/*  if  there  are    not  any  errors,  give  emissions 

if  ( ! err_cnt  ) 

*  (emit  ptr  Z®1     +     (-*(  emi t pt r [£]  ))) 

*  (emit ptr CI]  +  ( * (  emit ptr C£3  >>) 
++(*  (emit ptr C£3 )) ; 

> 


*/ 


node ; 
ch  i  Id  ; 


fls  can  be  seen,  this  revised  version  is  not  restricted  to 
emit  code  into  emission  table  all  the  time.    It  can    emit  code 
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into  a.riy  table  which  is  addressed  by  "emitptr"  pointers.  That 
is,  by  setting  these  pointers  somewhere  else,  we  can 
"redirect"  the  emissions. 

The  following  routine  directs  emissions  into  a  given 
pointer  set.  This  given  pointer  set  is  supposed  to  be 
pointing  to  a  table,  of  the  same  type  as  the  emission  table. 


drct_ernit  (ornit_ptr,  ptrl,  ptr£,  ptr3)  /*  direct  emits  */ 
int    *emi t _pt r C3 ,      /*  pointer  set  to  emissions      •*/ 

ptrl  CD       , 

ptr£C3       , 

*ptr3        ;     /-*  pointers  to  new  direction     */ 


emi  t  _ptr  CiZG=ptr  1 
emi t _pt r  CI] =pt r£ 
emi t _pt r  C£D  =ptr3 


As  we  have  seen  before,  our  em  it -code  routine  emits 
into  a  table,  pointed  to  by  the  "emitptr"  global  emission 
pointers.  But,  if  we  redirect  these  pointers  into  somewhere 
else,  don't  we  lose  the  address  of  the  previous  table?  So,  we 
have  to  be  able  to  save  our  previous  emission  addresses 
somewhere.  The  following  routine  saves  these  pointer 
addresses  in  given  ones. 


/•*  saving  emit  pointer? 


*/ 


rplc_»mitB (ptr_a, ptr_b) 
int    *ptr_a  CD , 

■*ptr_bCU;         /*  pointer  sets  to  both  emit-tables  -*/ 
■C 

ptr_aCiZi]=ptr_bCiZi:  ; 

ptr_aCi:=ptr_bCi:  ; 

ptr_a C£] =ptr_bC£D ; 


find   the  very  last  problem:   We  3.ve    able  to  redirect   our 
"emitptr"  emission  pointers  into  some  tables   (then  obviously 


successive  emissions  are  then  entered  into  these  tables) .  We 
are  able  to  save  the  previous  value  of  these  pointers.  But 
what  about  the  "postponed  emissions".  Namely  the  ones  we 
saved  somewhere  else  other  than  our  emission  table.  The 
following  routine  transfers  previously  saved  emissions  from 
one  table  into  another. 


tms_emits <emit_a,  emit_b)      /*  transfer  emits        */ 

int    *emi t _a [] ,        /*  destination  table  pointers    •*/ 

*emit_bC];        /-*  source  table  pointers         */ 


■C 


char  i ; 

for     (i=iZi;     i<     (    *  (emi  t  _b  I  Ell  )  )  ;     ++i) 

*  <    emit_aC0]     +     (    *  (ernit_aC£D  )  )  )     =    *  (ernit^bCiZU  +  i  )  ; 
* (    em  i  t  _a  C 1 1     +     (    *  ( em  i t  _a  CS3  >  >  )     =    *  < em  it_bC13+i)  ; 

++ (     * (emit_aC£3 ) ) ; 

> 


H.  CODE  OPTIMIZATION 

Under  normal  conditions,  code  optimization  ca.n  be  done 
on  both  intermediate  code  and  target  code.  When  generating 
target  code,  compilers  attempt  to  find  the  best  code 
generation  sequence,  eliminate  common  sub-expressions, 
minimize  the  number  of  temporary  variables.  find  after 
code  generation  is  done,  they  pass  through  it  again  arte  or 
two  times,  for  peep— hole  optimization,  jump  optimization, 
etc. 

Our  Tiny-C  intermediate  code  has  a  flattened  tree 
structure;  it  is  possible  to  traverse  it  as  a  tree.  In  order 
to    do   this,   we  will  need  some  interface  routines   between 


this  flattened,  form  and  a  real  tree  structure.  Then  we  can 
logically  look  at  it  as  a  tree  and  travel  from  root  to  leaves 
or  vice-versa. 

In  this  thesis  work,  it  was  decided  to  generate  code  as 
quickly  and  simply  as  possible.  So  the  Tiny-C  compiler  uses 
sequential  code  generation,  even  though  it  is  not  the  best 
way  to  do  it. 

Since  our  code  is  going  to  be  source  code  for  the  ftM 
assembler,  it  is  not  going  to  be  easy  to  work  on  a  "text" 
file,  to  optimize  it.  fit  this  point,  we  can  work  on  our 
intermediate  code  to  make  it  more  effective.  So,  contrary  to 
the  classical  compilers,  our  code  optimization  is  going  to  be 
only  on  intermediate  code,  instead  of  both  intermediate  and 
target  codes. 

There  are  several  things  we  do  in  the  code  optimization 
phase : 

—  Removing  dead  code 

—  Label  /.jump  optimization 

—  Emitting  imbedded  assignments 

The  last  one  cannot  be  classified  as  part  of  code 
optimization  phase,  although  we  deliberately  left  it  to  this 
point.   We  will  see  why  pretty  soon. 

1.   Dead  Code  Elimination 

In   some  cases,   the  Tiny-C  compiler  generates   dead- 
code.  For  instance: 
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In  the  intermediate  code  list,  there  is  a  node, 
called  "DUMMY".  Sometimes  our  parser  may  emit  some  code,  but 
then  it  may  realize  that  this  code  is  not  necessary.  In  that 
case  emitting  a  "DUMMY"  node  makes  this  previous  code  "out 
of  cor\cerrt"       or   a  "dummy  statement". 

In  fact,  such  a  tool  is  not  truly  necessary,  but  was  used 
in  early  versions  of  the  compiler.  In  the  following  phases 
this  "DUMMY"  node  was  used  only  in  the  "case"  statement.  Due 
to  constraints  on  time,  it  has  not  been  removed. 

As  we  discussed  before,  this  thesis  is  a  presentation  of 
the  first  version  of  the  Tiny-C  compiler,  and  hopefully  a 
reference  for  its  future  authors,  rather  than  a  discussion 
about  compiler  writing  techniques. 

Nevertheless,  to  simplify  the  tree  we  can  remove  this 
"DUMMY"  node  and  its  children. 

In  addition,  there  may  be  dead-code  that  is  generated  by 
the  compiler.  An  example: 

Jo«  -  5 | 

goto  there; 
jo«  •■  jimmy*5| 
++J immy ; 
thervi 

Here   two  statements,     in  the  third  and  fourth  lines  are 

dead  code.    They  will  r\ever    be  used.   So,  we  can  remove  this 

dead  code  from  the  parse  tree. 

2.  Dead  Label  Elimination 
In   general,   any    label   declaration  is   automatically   the 
beginning   of    a   new  basic  block.   However  if  there   is   no 


"goto"  for  this  label,   then  such  a  label  is  part  of  a  larger 
basic  block. 

Having  basic  blocks  as  large  as  possible  removes  the 
amount  of  data  transfer  between  registers  and  memory.  In 
other  words  it  reduces  the  number  of  "register  cleaning" 
operat  ions. 

So,  if  we  detect  labels,  which  are  declared  but  r\ever 
used,  removing  them  is  going  to  be  ar\    improvement. 

3.   Temporary  Variables  in  the  Front  End 

There    is   one  more  thing  that  has  to  be   done   when 
passing  over   the  intermediate  code  for  optimizing  purposes. 

In  the  parser,  arithmetic  expressions  following  a 
"switch"  reserved  word  ax^e  assigned  to  some  temporary 
variables.  These  temporary  variables  ax^e  represented  by 
"TVAR"  nodes,  with  a  temporary  variable  number.  Since  the 
result  of  those  arithmetic  expressions  are  assigned  to 
"TVAR"  nodes,  and  these  variables  are  compared  with  "case" 
labels,  we  have  to  allocate  memory  for  these  nodes  just  as 
we  are  going  to  do  for  normal  variables.  The  values  of 
"TVAR"  nodes  may  or  may  not  reside  in  their  allocated  memory 
locations,  they  may  be  kept  in  registers,  too.  The  register 
manager  in  the  following  section  will  treat  them  Just 
like   variable  nodes. 

In  fact,  all  variables  ax^e  referred  to  by  their 
symbol  numbers,  or  their  symbol  table  entry  numbers.  And  at 
this  point,  we  know  our  symbol  table  length.  So  we  can  assign 
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some   new  symbol  numbers   to  these  "TVAR"  nodes,    and  change 
their   names   to  "VARB"  variable   nodes.   Then   the   register 
manager  can  take  care  of  the  rest. 
4.   Code  Optimization,  Phase  1. 

The  following  routine  is  the  first  part  of  the 
intermediate  code  optimization,  and  is  called  just  after  the 
parser. 


frmtoptO    /*  first  pass  of  optimization    */ 
■C 

-  Detects  dead-code  and  replaces  it  with  "NOOP"  no 
operation   nodes. 

-  Detects  unused  labels  and  replaces  them  with  "NOOP" 
nodes. 

-  Replaces  "TVAR"  nodes  with  "VARB"  nodes  and  assigns 
them  new  symbol  numbers  starting  from  the  last  symbol  number 
in  symbol  table. 

> 


5.   Separation  of  Front  End  and  Code  Generator 

Up  to  now,  our  intermediate  code  has  been  in  memory, 
in  its  allocated  location  (emission  table).  The  emission 
table  has  to  be  large  enough  to  be  able  to  keep  the  largest 
size  program  in  it,  because  of  its  fixed  size.  If  the  input 
source  file  is  too  big  to  fit  into  our  emission  table,  Tiny-C 
responds  with  art  error  message.  (This  is  one  of  the  reasons 
it  is  called  Tiny-C). 

It  is  possible  to  pass  this  emission  table  to  the  second, 
target  machine  dependent  part  of  compiler,  but  it  would 
not  be  efficient. 
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There  is  a  logical  separation  between  parser/ 
intermediate  code  generator  and  target  code  generator. 
The  first  part  is  totally  language  dependent  and  machine 
independent,  and  the  second  part  is  machine  dependent  but 
language  independent.  So,  putting  a  physical  separation 
between  these  logically  independent  units  is  always  a  good 
idea,   and  has  been  implemented  in  most   compilers. 

For  this  reason  we  should  end  the  first  part  of 
this  compiler  here.  But  before  doing  this,  we  have  to  pass 
the  outcome  of  this  part  to  the  second  part  of  compiler 
(basically,  the  code  generator  of  Tiny-C) . 

The  code   generator   is  going  to  need  intermediate   code, 
a   symbol   table,    a   constant   table,   and   the   number   of 
temporary  variables  used  by  the  parser.   fill  this  information 
has  to  be  written  in  some  place  for  later  access  by  the   code 
generator. 

But  we  have  a  last  minute  problem  here,  which  we 
deliberately  ignored  up  to  now.  This  is  "imbedded 
assi  gnments.  " 

6.   Imbedded  Piss i  gnments 

In  the  C  language  the  statement; 
Jo»  ■  jimmy++  »  5| 
is  in  fact  two  different  statements: 


jo«  ■  Jimmy  *  5;  and  a  following: 
++j  immy | 
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The  second  statement  here  is  an  "imbedded  assignment."  We 
didn't  emit  code  for  imbedded  assignments  up  to  now,  and  in 
fact  we  have  ignored  this  problem  on  purpose.  Because  right 
now,  when  writing  intermediate  code  into  a  quad  file,  we 
can   simply  emit  these  codes  without  any  effort. 

7.   Code  Optimization,  Phase  c.'.  The  Quad  File  Filter 

The  following  routine  is  the  second  part  of  the 
intermediate  code  optimizer.  It  is  called  just  after  the 
first-pass  optimizer. 

mcndopt < )       /*  second-pass  optimization    */ 
Creates  a  quad  file  named  "TC. QQQ"  and: 

-  Writes    intermediate   code   in   this    file,     without 
"NOOP"  codes  and  with  additional  imbedded  assignments. 

-  Marks  end  of  intermediate  code 

-  Writes  symbol  table 

-  Writes  number  of  the  temporary  variables  <TVARs) 

-  Writes  constant  table 

-  Writes  name  string 

-  find  closes  that  quad  file. 

> 

I.  DATA  STRUCTURES  FOR  CODE  GENERATION 

The  final  step  is  code  generation  for  the  Abstract 
Mach ine. 

As  discussed  before,  the  output  of  this  compiler  is  not 
going  to  be  binary  code  which  is  ready  to  be  linked  and 
run.  It  is  going  to  be  a  source  file  for  the  AM  assembler, 
so  it  will  be  readable. 
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Since  this  is  the  second  part  of  the  compiler,  it 
receives  the  work  done  in  the  first  part.  The  following 
routine  reads  a  Tiny-C  quad  file  from  the  disk. 


r#*d_qu*d()      /*  read  quad  file        ■*/ 
■C 

Reads   quad  file  from  disk  in  a  sequence  of   intermediate 
code,  symbol  table,  constant  table  and  name  string. 

> 


Now  the  compiler  has  all  the  information  it  needs  to  go 
ahead  and  generate  code.  But  right  now  it  does  not  have  any 
tools  to  do  this.  We  build  some  tools  first,  to  help  the 
code  generation  phase. 

The  target  machine  AM  theoretically  has  an  unlimited 
number  of  registers.  This  is  not  realistic.  So,  the  Tiny-C 
compiler  considers  .  that  AM  has  a  reasonable  number  of 
registers,  and  tries  to  manage  them  properly. 

Keeping  all  the  variables  and  all  the  intermediate 
results  in  registers  would  be  awfully  nice.  But  since  this  is 
impossible  and  we  are  going  to  run  out  of  registers  after 
generating  a  piece  of  code,  we  will  need  a  "register 
manager"  to  handle  the  limited  number  of  registers 
properly.  Tiny-C  compiler  does  not  have  a  single  "register 
manager"  routine.  Instead,  we  will  introduce  a  couple  of 
routines,  which  manage  AM  registers  properly. 

1.   Address  Descriptors 

As   it   is   known,   a  compiler  cannot   keep   all   the 
variables  in  registers   all  the   time.    So,    it   is   obvious 


4iZi 


that    a   variable   may   be   in    a   register,    or    in   its 
allocated  memory  location,   or  both,   at   a  particular   time. 
A  compiler   needs  a  mechanism  to  keep   track   of   the  current 
addresses  of  all  variables.  The  following  routine  sets  symbol 
addresses  by  given  parameters. 


addr_dscr (sym_no, status, rsg_.no)  /*  symbol  addr.  descriptor*/ 

char     sym_.no,  /*  symbol  number  */ 

status,  /*  address  status  */ 

reg_no;  /*  register  number         •*/ 

■C 

Sets  current  addresses  of  variables.    All  variables 
have  Ar\         8-bit   value   address  descriptor.   Status  may   be 
"in— register",   "in— memory"   or  "in- both".    If   7th   bit   of 
this   descriptor   is    1,    that  means   variable   is   in   its 
allocated  memory  location.     If  the  value  stored  in  bits  «Zi  to 
6   is  zero,   means  variable  is  not  in  any  register.    If  it  it 
different  from  zero,   that  value  minus  one  gives  the  register 
number  which  symbol  is  stored  in. 
> 


Exactly   the   same  problem   exists   for   constants.   Even 
though   constant   values   are   fixed  and   they   reside   in   a 
constant  table  all  the  time,  the  compiler  should  not  transfer 
a   constant   value  into   a  register  if  it  is  already  in   one. 
The  following  routine  sets  a  constant  address  descriptor. 


cnst_sdr_dscr  <cnst_no, status, r»g_nc) 

int      cnst_no;  /*  constant  number  ■*/ 

char     status,  /*  status  */ 

reg_no;  /*  register  number  */ 

< 

Sets  current  addresses  of  constants.  fill  constants  have 
An  8-bit  value  address  descriptor.  If  7th  bit  of  this  value 
is  1,    and  all  others  are  zero,   that  means  the  constant   is 

not  in  any  register.   Otherwise  the  value   of  this  descriptor 

gives  the  register  number  which  the  constant   resides  in. 

> 
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£.   Temporary  Management 

There  is  one  more  address  problem.  When 
calculating  an  arithmetic  expression,  we  may  have  a  couple 
of  temporary  results.  For  instance: 

"Jo*- jimmy   *  5  *  Jo«  *  3;" 
The  statement  has  the  following  parse  tree: 

assignment 

variable  addition 

joe        multiplication        multiplication 

variable     constant   variable    constant 

j  i  mmy  5  j  oe  3 

Here,  the  compiler  calculates  "jimmy  *  5"  and  "joe  *  3" 
first.  Since  it  has  to  keep  these  results  somewhere 
temporarily,  we  have  to  manage  these  temporaries  and 
keep   track   of   their  addresses. 

Tiny-C  compiler  manages  temporaries'  addresses  exactly  in 
the  same  way  as  it  does  for  variables.  In  addition,  it  may 
dispose  a  temporary,  so  we  car\  use  the  same  temporary  number 
somewhere  else  later. 


disposa_temp (temp_no)    /*  dispose  temporary     */ 
char     temp_no; 

Disposes  the  given  temporary  variable. 

> 
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Uhen  the  code  generator  finishes  a  statement  completely, 
there  is  no  need  for  any  temporary,  in  Tiny-C s  sequential 
code  generation  order.  So  at  the  end  of  every  statement, 
the  compiler  disposes  of  temporary  variables. 


clean_t»rnp»  O        /*  clean  all  temporaries  */ 
■C 

Disposes  all  the  temporaries. 
> 


Compiler  needs  a  new  temporary  every  time  it  calculates  a 
temporary  result.  So,  the  following  routines  provide  new 
temporaries  to  the  code  generator. 

gat _*_t«mp  < t»mp_no)       /*  get  a  temporary  variable   */ 

char     *temp_no; 

-C 

Finds  s.ri    unused  temporary,  returns  its  number  to  the  code 
generator,  and  marks  it  "used.  " 
> 

3.  Finding  Current  Addresses 

The  compiler  should  be  able  to  figure  out  any  given 
token's  address  at  any  time.  Tiny— C  uses  the  following 
routines  for  this  purpose. 

i*_inr«g  <tokan_.no,  kind)     /*  is  token  in  a  register?     */ 
int      token_no;  /*  token  number  -*/ 

char     kind;  /*  token  kind  */ 

■C 

Takes    token   kind  (variable,   constant  or   a   temporary 

variable)  and  its  token  number,  returns   TRUE  if  it  is  stored 
in  a   register,   else   returns  FALSE. 
> 

If    a   particular   token  is  in  a  register,     it  cart       be 

figured  out  which  register  this  one  is. 


get_reg_nurn(token_no,  reg,  kind)  /*  get  register  number     */ 

int      token_.no;  /*  token  number         */ 

char     *reg,  /*  register  number      */ 

kind;  /*  token  ki nd           * / 
■C 

Takes   a   token  number  and  its   kind,   and   returns    its 
register  number  in  "reg"  pointer. 
> 


After  some  operations,  variable  values  may  be  only 
in  registers,  and  may  not  be  in  their  allocated  memory 
locations.  The  compiler  should  figure  out  if  a  given  varible 
is  in  memory,  to  avoid  transferring  it  into  its  memory 
location  unnecessarily. 


iminmem  («ym_no)  /*  is  symbol  in  memory?      -*/ 

char     sym_no;  /*  variable's  symbol  number  */  ' 

{. 

Checks  variable's  address  descriptor,   returns  TRUE  if  it 
is  in  memory,  else  returns  FALSE. 
> 


4«   Register  Management 

A  register  can  hold  Just  one  single  value.  But  in 
the  Tiny— C  compiler,  this  value  can  belong  to  more  than 
one  token  at  the  same  time;  for  instance  the  same  register 
car\  keep  two  variables,  one  constant  and  two  temporary 
variables  in  it  if  they  all  have  the  same  value  at  that 
particular  time. 

We    will   define  the  structure  of  the  register    manager 

1  ike  this: 

ttdefine   MXREG   16      /*  #  of  target  machine's  registers  */ 
ttdefine   MXVAR   5       /*  maximum  #  of  variables  that 

one  single  register  ca.r\    hold  ■*/ 

int      *regtr CMXREG] ,  /*  pointers  to  register  variables  •*/ 

reg_arr  CMXREG*MXVARD ;  /*  register  variable  affray  */ 
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So,  every  register  has  an  amount  MXVAR  of  register 
array  (reg_arr)  locations.  These  a.r&  token  descriptors  and 
shows  which  tokens  (variables,  constants  and  temporaries) 
that  particular  register  has  at  any  time.  The  size  of  the 
register  array   is   MX  RES  times  MXVAR. 

The  register  array  keeps  the  names  of  the  tokens  which 
are  loaded  in  some  registers. 

Since  particular  parts  of  the  register  array  belong  to 
particular  registers,  we  cari  easily  figure  out  which  tokens 
are       in   which  registers,  or  which  register  has  which  tokens. 

In  order  to  calculate  a  new  result,  the  compiler  has  to 
find  an  unused  register  to  load  the  value.  The  following 
routine  provides  free  registers  to  the  code  generator. 


g«t_*_r»g <r«g) 
char     *reg 5 


/*  get  a  register 
/*  register  number 


*/ 
*/ 


Checks  every  registers  register  array  locations.  If  finds 

a  blank  one,  returns  this  register  to  code  generator.  If  they 

are  all  occupied,  evacuates  one  of  them  randomly,  and  returns 
it. 

> 

The  compiler   should  be  able  to  load  a   token   from   its 

memory  location   into  one  of  the  registers.   The   following 

routine  is  used  for  this  purpose. 


load_in_reg (tok§n_no, rag, kind)  /*  load  into  a  register    */ 
int      token_no;  /*  token  number  */ 

char     *reg,  /*  register  number         ■*/ 

kind;  /*  token  kind  •*/ 

-C 

Takes    a  register,   a  token  number  and   its   kind,    and 
generates  code  to  load  it  into  that  given  register. 
> 


After  loading  this  token  into  a  register,  its  address 
descriptor  has  to  be  set  as  "in  both  register  and  memory", 
and  the  register  manager  should  set  the  members  of  this 
particular  register. 

Suppose  we  load  an  integer  value  "3"  into  a 
register.  The  register  manager  should  know  that  the  register 
is  keeping  a  constant  value  "3",  or  which  constant  number 
from  our  constant  table  is  in  that  register. 

Then,    suppose   we  assign  this  constant  to   a   variable, 
like  in  the  statement:  "Joe=3. " 

The  register  manager  should  mark  that  this  particular 
register  has  a  constant  and  a  variable  in  it. 

The  following  routine  helps  the  register  manager  to  state 
that  a  register  is  now  holding  a  given  token. 


occupy_r«g <tokan_no, reg, kind)   /*  occupy  register  */ 

int      token_no;  /*  token  number  */ 

char     *reg,  /*  register  number  */ 

kind;  /*  token  kind  */ 

■C 

Enters   given  token  into  given  register's  register  array 

location,   to   mark  that  this  register  is  holding  that  given 
token  in  it. 
> 


There  may  be  times  when  the  compiler  assigns  a  new 
value  to  a  variable  but  that  particular  variable  may 
have  been  stored  in  a  different  register  before.  Since  we 
want  to  bind  a  new  register  to  the  old  variable,  we  want  to 
release  its  old  register. 
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rml_.uym_.rmQ  (»ym_no)    /*  release  symbols' s  register  */ 

int      sym_no ; 

■C 

Takes   a  variable,   finds  its  register,   and  deletes   its 
membership  to  this  register. 

> 


Sometimes  the  compiler  has  to  store  a  token  from  its 
register  into  its  memory  location.  The  following  two  routines 
do  this  chore. 


•v*_»ymbol («ym_no, r»g_no) /*  evacuate  register  from  symbol  */ 

char     syrn_no,  reg_no; 

-C 

Generates   code   to   transfer  symbol  from   register   into 
memory.   Then   sets   the  symbol's  address  descriptor   as   "in 
memory"  only. 
> 


•v*_t»mp < t»mp_no, r»g_no)  /*  take  temporary  out  of  register*/ 

char     ternp_no,  reg_no; 

■C 

Generates  code  to  transfer  temporary  from  register  into 
memory.  Then  sets  its  address  descriptor  as  "in  memory"  only. 
> 


find  there  are  some  cases  when  compiler  wants  to  empty  a 
register  completely.  For  instance,  we  may  do  this  to  release 
a  register. 


•v*_r»g <r»g_no>  /*  evacuate  register     */ 

char     reg_no; 

-C 

Takes   a   register  number,   finds  all  its  members  in   the 
register  array,   and  generates  code  to  transfer  those  members 
to   their   memory  locations  if  they  a.re       not   already   there. 
(Uses  above  two  routines,  actually). 
> 


Before  getting  out  of  a  basic  block,   the  compiler  should 
empty  all  registers.  The  following  routine  does  this  task. 
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cl©an_r»gs()  /*  clean  registers       */ 

-C 

Calls  "evacuate  register"  routine  for  all  registers. 

> 


5.   Operands  for  the  Operators 

In    the  actual  code  generation  phase,    the  compiler 
looks   for   an  operator,   and  according  to   operator's   type, 
requests   the   registers   for   operands.   The   following   two 
routines  return  integer  operands  in  registers. 


load_two_oprnd <j, rl,  r£,  step)   /*  load  two  integer  operand   */ 
int       j ;  /*  pointer  to  int.  code       */ 

char     *rl,  *r£,  /*  registers  */ 

♦step;  /*  #  of  the  total  steps  taken*/ 

•C 

Gets  two  operands  frrfm  intermediate  code,  loads  them 
into  two  available  registers,  and  returns  these  register 
numbers  to  the  code  generator.  Since  our  parse  tree  is  in 
a  flattened  form,  the  code  generator  needs  to  know  where  it 
came  in  that  array-tree,  after  loading  these  operands.  So, 
the  "step"  is  a  variable  that  tells  how  many  steps  have 
been  consumed  in  the  intermediate  code. 
> 


lo*d_on«.opmd  (i,  rtg,  Bttp)     /*  load  one  integer  operand   */ 
int      i  ;  /*  pointer  to  int.  code       */ 

char     *reg,  /*  register  number  */ 

*step;  /*  #  of  the  total  steps  taken*/ 

■C 

Loads   the   next   operand   in   the   parse   tree   into    a 
register,  and   returns  the  register  number  with  the  number  of 
steps   walked  in  the   parse  tree. 
> 


The  Abstract  Machine  AM,  has  some  boolean  operators 
that  accept  only  boolean  operands.  But  everything  in  Tiny— C 
has  integer  type.  So  the  code  generator  should  have  some 
tools    to  cortvert  integer    values   into   booleans.    The 
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following  two  routines    provide  boolean  operands  for  boolean 
operators,  whenever  they  are  needed. 


two_bool <J, r lf r£, stap)   /*  load  two  boolean  operand   */ 
int      j;  /*  pointer  to  int.  code       •*/ 

char     *rl,  *r£,         /*  registers  */ 

♦step;  /*  #  of  the  total  steps  taken*/ 

-C 

Loads  two  operands.    If  they  have  integer  values  it  loads 
the   corresponding  boolean  values  into  registers  and   returns 
them  to  the  code  generator. 
> 


one_bool  (  if  r«g_nof  step)  /*  load  one  boolean  opmd     */ 

int       i;  /*  pointer  to  int.  code       */ 

char     *reg_no,  /*  register  number  •*/ 

♦step;  /*  #  of  the  total  steps  taken*/ 
■C 

Returns  one  boolean  operand  into  a  register. 
> 


J.  CODE  GENERATION 

In   the   Tiny-C  compiler,   the  main  routine  in   the  code 

generator   is   a   large  switch  statement  as  is  used   in  most 
compilers.   The  compiler  generates  code  for  the  data   segment 

first,   which   is   just  a  memory  allocation  routine   for  the 

symbols.   Then   the   code   segment  comes  as  the   actual  code 

generation  phase.   The  following  routine  is  a  subset  of  the 

code   generation   routine   for  the  code   segment.   Each  case 
element  dispatches  to  the  code  emitter  for  that  case. 


cod»_aeg ()  /*  give  code  segment  */ 

int      i;         /*  index  variable  */ 

char     rl,r£,    /*  register  numbers  */ 

/*  walk  emit  arr^y    from  beginning  to  em it -end      */ 
for  (i=i3;  i<  em  it  end;  ++i) 


A3 


/*  if  node  has  children,   (if  it  is  not  a  leaf)  */ 
if  (emitchl CiD ! =0  ) 

switch  (  emitstrCiD  ) 

■C 


case   I ODD   :   /*  integer  addition  */ 

code_iadd ( i , &st ep) ; 
break; 


case   MEND   :   /*  end  of  main  function   */ 

fprintf (f 1, "     stop\n") ; 
break ; 
> 
> 


The   following  routine  is  used  by  the  above   "code_seg() 
routine  and  emits  code  for  integer  additions. 


code_iadd  ( i ,  step)     /*  integer  addition  ■*/ 

int       i  ; 

char     *step;         /*  #  of  the  steps  taken  on  int.  code  */ 

■C 

char     rl,r£,     /*  register  numbers  ■*/ 

temp_no;  /*  temporary  variable  number  */ 

/*  load  two  operands      •*/ 

load_two_oprnd (i-1, &rl, &r£, step) ; 

/*  they  both  might  be  in  the  same  register, 

if  so,  allocate  one  more  register  */ 
if  <rl==r£:) 
-C 

get _a_reg (&r 1 ) ; 

fprintf  (fl,  "     mov      r  <0:*d)  ,  r  (iZi:"/.d)  \n",  r£,  rl )  ; 
> 

/*  since  addition  will  be  loaded  in  rl,  evacuate  it  first  */ 
eva_reg (r 1 ) ; 

/*  code  for  integer  addition      */ 

fprintfCfl,"        add      r (0 : %d ) , r (0 : %d ) \n" , r£, r 1 ) ; 
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/*    give    a    number    to    this    temporary    result  */ 

get  _a_t  ernp  (  &t  emp_no) ; 
occupy _reg  (ternp_no,  rl,  TEMP)  ; 

/*    set    temporary's    address    descriptor  */ 

temp_var  [t  ernp_no]  =r  1  +  1  ; 

/*  validate  emission  array  for  sequential  code  generation  •*/ 

emitstrCi3=TEMP; 

ernitchl  C  i  ]  =*st ep+1  ; 

emi tstr  C i-1 1 =temp_no; 
> 


Some  sample  C  programs  and  the  code  generated  for  them  by 
the  Tiny-C  compiler  can  be  found  in  Appendix  F. 


v".  CONCLUSION 

Precise,  understandable  and  enforcable  interface 
standards  car\  provide  a  way  to  improve  efforts  toward 
portable  software.  In  the  Tiny-C  implementation  we  showed  a 
way  to  improve  the  programming  capabilities  of  AM,  and  encou- 
raged programmers  to  use  such  a  portable  and  st andard 1 zable 
machine  in  high  level  languages. 

Unfortunately,  this  implementation  is  not  completely 
satisfactory.  Because  of  restricted  capabilities  in  the 
target  AM  machine,  the  Tiny-C  compiler  does  not  fully 
support  application  programming.  Some  of  these  restrictions 
are : 

—  Based  on  the  principle  of  resource  abstraction,  AM  has 
strictly  defined  data  types.*  Since  it  presently  does  not 
support  conversion  between  two  types,  it  is  a  higher 
level  concept  than  the  "C"  language.  So,  contrary  to 
usual  implementations,  this  thesis  had  art  opposite 
direction:  production  of  a  lower  level  tool  in  a  higher 
level  environment. 

—  The   AM    abstract  machine  does  not  yet  have   a   complete 
linker.    So,   the   user    is   forced  to   keep  the   whole 
program    and  input /out  put  library  in  one  single   module, 
which   is  extremely  inconvenient  in  application   environ- 
ments. 

—  The  current  version  of  AM  is  an  emulator,  rather  than 
hardware.  Even  though  this  is  convenient  for  a  develop- 
ment phase,  it  is  not  going  to  be  ar\  easy-to-use  product 
for  users. 

So,   further   development   that   could   be   done   for  an 

improved  AM  environment  might  include: 

—  A  linker  for  AM 

—  Type  conversion  between  AM  data  types 
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-  An  input/output  library  for  the  Tiny-C  compiler 

-  A  Tiny-C  code  generator  for  AM  machine  code  (instead  of 
a  source  generator  for  the  AM  Asernbler) 

-  Given  improvements  in  AM,  an  extended  version  of  the 
Tiny-C  compiler  to  cover  the  whole  Tiny-C  language 
grammar 


-  A  compiler  version  of  AM. 


APPENDIX  PI 


GRAMMAR  FOR  TINY-C  LANGUAGE 


PROGRAM  : 


program: 


<pre-precessor)  *   <dat a-def ini t  ion) * 
(funct ion— def ini t ion) + 


PRE-PRECESSQR  : 

pre-precessor : 

"#def ine"    <f i le-def ini t ion) 
" #  i  nc  1 ude"   <  f  i 1 e-de  f  in i t  i on) 

f i le— def ini t  ion : 

'  '"         <f  ilenarne)        '  "'  I 

'  <'         <f  ilenarne)        '  )  ' 

f  i  lenarne : 

(identifier)        <filetype) 

f i letype : 

' . '         <ident  i  f ier) 


DATA    DEFINITIONS     : 


data— def ini t  ion : 

<sc-speci f ier) ? 


<declarat  ion) 


sc-speci  f ier : 
"auto" 
"static" 
"extern" 
"register" 


declarat  ion: 

<t ype-speci  f ier) 


<var i able-dec lar at  ion— 1 ist ) 


ii  .  ii 
i 


t ype-speci  f ier : 
"char" 
"short" 
"int" 
"long" 
"unsigned" 
"float" 
"double" 


var i able-dec larat ion— 1 ist : 

(variable-declarat ion)    (more-vari able-dec larat ions) * 

cnore-vari  able-dec  larat  ions  : 

','    (variable-declaration) 

DECLARATIONS  : 

variable-declarat  ion : 

"*"?   (identifier)    <index-declarat ion) ?   (initializer)? 

index -dec larat  ion : 

"C"   (const  ant -ex  press ion)  (1)   "]" 

initiali  zer : 

"="   (primary) 

primary : 

(  ident  i  f ier)  I 

(constant)  I 

(char-definition)  I 

(string) 

char-def ini t  ion : 

"'  "   (character)   "'  " 

string : 

"""   (character)*   " "" 


FUNCTION  DEFINITION  : 

funct ion— def  init ion : 

(type— speci f ier) ?   (function-declaration)    (function-body) 

funct  ion-dec larat  ion : 

(identifier)   "("   (  ident i f ier- 1 i st > ?   ")" 

ident  i  f iei — 1 ist : 

( ident  i  f ier)    (more- ident  i  f iers) * 

more- ident  i  f iers : 

'  ,  '    (  ident  i  f ier) 

funct  ion— body : 

(type-dec  1-1 ist )    (compound-statement) 


PARAMETER  DECLflRAT IONS  ; 

type-declarat ion— 1 ist : 

< paramet er-dec 1 ar at  ion)  + 


paramet  er-dec 1 arat ion: 

<type-speci  f ier>    < paramet er-dec 1 arat  ion— 1 ist  > 


paramet er-dec 1 arat  ion— 1 ist : 

(parameter)     (more-parameters) 

more-parameters : 

' , '    (parameter) 

parameter: 

' *' ?   (identifier)    (index-declaration)? 


STATEMENTS 


statement : 

(compound— statement ) 
(function-call)   ";" 
(assi  gnrnent -statement ) 
( i  f -st  at  ement ) 
(whi le— statement ) 
(do— statement > 
( f or— st  at  ement ) 
(switch— statement  > 
(break-statement ) 
"continue"   ";" 
(ret  urn-statement ) 
(goto— statement ) 
(label) 


compound-statement : 

"-C"   (declaration)* 


(statement ) 


">' 


f unct  ion-cal 1  : 

( ident  i  f ier) 


( 


(ex press i on- 1 ist ) 


e x press i on- 1 ist : 

(expression)    (more-expressions) * 


more-expressions : 

' , '    (expression) 


assi gnrnent -stat ement : 
(assi  gnrnent ) 
( i  ncrement  a  1 -ex  press  i  on) 


assi  gnrnent  : 

(lvalue)  "  =  "        (logic-expression) 

(lvalue)  <sh i f t-assi gnrnent— op>        (sh i f t_expression) 

(lvalue)  (bi t wi se-assi  gnrnent— op >        (bitwise-expression) 


sh  i  f  t-assi  gnrnent— op  : 

"+="     |     '<_=»     |     "*="     |     "/="     I     "%="     I     M))="     |     "<<  =  •■ 

bit  wise -as  si  gnrnent —op  : 

"  &=  "     |     "  •"•=  "     |     M  |  =  " 

i  ncrement  a  1 -expression : 

"++"        (lvalue)  I 

(lvalue)  I 

(lvalue)        "++"  I 

(lvalue) 


i  f -st  at  ernent  : 

"if"   "("   (logic-expression)   ")"   (statement) 
(else-statement) ? 

e  1  se— st  at  ernent  : 

"else"        (statement) 

wh  i  1  e-st  at  ernent  : 

"while"   "("   (logic-expression)   ")"   (statement) 

do-statement : 

"do"   (statement)   "while"   ' ('    (logic-expression)   ')' 


for— statement : 

"for"        "("        (ass  l  gnrnent- 1  ist )  ?       ";"        (logic-expression) 
;"        (assignment-list)?       " ) "        (statement) 


■I  .  it 


assi  gnrnent -1  ist  : 

(assi  gnrnent -st  at  ernent )         (more-ass  i  gnrnent  s)  * 

more-ass  i  gnrnent  s  : 

','         (assignment-statement) 

switch-statement : 

"switch"        "("        (arithmetic-expression)        ")"        "-C" 
(case-stmt)+       ">" 

case-st  rnt  : 

"case"  I  "default"!    (constant-expression)   ":" 
(statement ) * 


break-statement : 

i 


"break" 
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ret  urn— statement : 

"return"   {expression)   ' ;' 

goto—statement : 

"goto"   < identifier)   ";" 

label : 

<  ident  i  f ier)    " : " 


EXPRESSIONS 


expression : 

(string)  I 

(pointer-expression)  I 

(address-expression)  I 

(logic-expression)  I 
(  i ncrernent  a  1  -ex press i on) 

pointer-expression : 

"*"   (array-element)  I 

"*"   (identifier)  I 

"*"   " <"   (arith-expr)   ") " 

address-expression: 

"&"        (array-element)  I 

"&"   (identifier) 

logic-expression : 

( log  ic-term)    (more- log  ic-terms) * 

more- 1 og  i  c-t  erms : 

"II"   (logic_term) 


log  ic-term : 

( logic- fact or)    (more- log  ic- factors) 

more- log  ic- factors : 

"&•&"   (logic-factor) 

log  ic-f actor : 

'  !  '  ?   (bitwise-expression)  I 

'.»'?   "("   (logic-expression)   ")" 

b  i  t  w  i  se_ex  press  i  on : 

"~"7        (bitwise-term)         (more-bi twise-t errns)  * 

more-bitwise-terms : 

"  I  "   (bit wise- term) 

bitwise-term: 

(bitwise-factor)    (more-bitwise-factors) * 


»a 


more— bit wise— factors : 

"•-•"   <  bit  wise-factor) 

bitwise-factor : 

(bitwise-element  >    <rnore-bit  wise— element  s>  * 

more-bit wise— element s : 

'  &'    (bitwise— element > 


bitwise— element : 

<cornpare-exrp>  I 

"<"        (bitwise-expression)        ")" 

compare-expression : 

<compare-terrn>         <rnore-compare-t  errns)  * 

more-corn  pare- terms  : 

(equal  ity-op>         <compare-t errn> 

equal i ty-op : 

it  __.  H        |        H  i  _  ii 

compare-term : 

<cornpare-f  act  or)        more— compare— fact  ors)  * 

more-corn  pare- factors  : 

<relat  ion-op)         (corn pare- fact or) 

relat  ion-op: 

ii/ii        I        ii  \    ii        I        ii   /..ii        i        ii  v  _  ii 

compare- f act or : 

(shift-expression)  I 

"("   (compare-expression)   ")" 

sh  i  ft -ex  press ion : 

(lvalue)         <shift-op)         <ar i th-expression)      I 
<ar it h-ex press ion) 

sh  i  ft -op : 

") >  "        I        "  <  <" 

ar it h-ex press ion : 

' -'  ?        (term)         <more-t errns)  * 

more— terms : 

<  add -op)         <terrn) 


add-op 


term : 

(factor)   (more- factors) * 

more— factors : 

<mult-op>    < factor) 

mult -op : 

"*"   |   "/"   I   ""/." 

factor : 

"("   <anth-expr)   ")" 
(constant— expression) 

<character-def ini t ion) 
(f unct  ion— cal 1 ) 

<  increment  a 1 -ex press ion) 
< lvalue) 

const  ant -ex  press  i  on : 
(constant) 
(constant— i dent i  f ier) 

1 val ue : 

< array-element)  I 

<  ident  i  f ier)  I 

<  po  i  nt er— ex  press i  on) 

array-element : 

(identifier)    (index) 

index : 

"C"   (ar it h— expression)   ' 


SEMANTIC  CONSTRAINTS  : 


(1)  Prohibited  for  extern  and  parameter  declarations.  Mandatory 
for  others. 
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APPENDIX  B 


TINY-C  PARSER  VERSION  1 


extern         char     bufCH,  nextch,  f unc_end ; 
extern  int      bufp,  glbptr,  line_no; 


program ()  /*  Tiny— C  Program        */ 

■C 

while  ( preprcs ( )  ) 

■ 

whi le  (data_def () ) 

? 

if  ( ! f unc_def < ) )  goto  quit; 

while  ( ! match (EOF) ) 
•C 

f unc_end=FALSE ; 

if  ( ! func.def <> ) 

goto  quit ; 
> 


ret  urn (TRUE)  ; 
quit:  ret  urn (FALSE)  ; 


preprcs ()  /*  pre— precessor         */ 

-C 

int   oldp=bufp,   1 inep=l ine_no; 

g 1 bptr=buf p ; 

if     (rnatchtoken("#def  ine    ")) 

if     ( ! cnst_id ( ) )  goto    quit 

5 

if  (! constant () )  goto  quit 

■ 

> 

else  if  C mat chtoken<"# include  ")) 

■C 

if  ( ! f i le_def ( ) )  goto  quit; 

> 
else  goto  quit ; 
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return (TRUE) ; 
quit:  bufp=oldp;        1 ine_no=l inep;   nextch=buf Cbuf pD ; 
ret  urn (FALSE)  ; 

> 


file_def()  /*    file    definition                 */ 
■C 

int       oldp=bufp,  1 inep=l ine_no ; 

char    li miter; 

if     (match  ('"')  )  1  irni ter='  "' 

? 

else    if     (match  ('<')  )  limiter='<' 

■ 

else  goto    quit 


if     (  !  f  i  1  enarne  ( )  )        goto    quit; 


if  (limiter==' "' ) 
■C 

if  (! match ('"') )  goto  quit; 

> 
else  if  (! match (')') )      goto  quit 


return (TRUE) ; 
quit:  bufp=oldp;        1 ine_no=l inep ;   nextch=buf Cbuf p] ; 

ret  urn (FALSE)  ; 
> 


filename ()  /*  file  name  */ 

•C 

if  (!id())  return (FALSE) ; 

if  (filetypeO) 

return (TRUE) ; 

> 


filetypeO  /*  file  type  */ 

■C 

int   oldp=bufp,   1 inep=l ine_no; 


if  (  ! mat ch ( '  . '  ) )   got o  quit; 
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i  f  (  !  i  d  ( )  )  goto  quit; 

return (TRUE) ; 
quit:  bufp=oldp;        1 ine_no=l inep ;   nextch=buf Cbuf pD ; 
ret  urn (FALSE)  ; 

> 


data_def()  /*  data  definition       */ 

-C 

int  oldp=bufp,  1 inep=l ine_no; 


g 1 bptr=buf p; 

i  f  (sc_spcf r ( )  ) 

5 

if  (dclrt  ionO  ) 

ret  urn (TRUE) 


quit:  bufp=oldp;        1 ine_no=l inep ;   next ch=buf Cbuf pi ; 
return (FALSE) ; 

> 


sc_spcfr()  /*  sc  specifier          */ 

if  (matchtokenC'auto  ")) 

else  if  (match token ( "stat ic  ")) 

■ 

else  if  ( mat ch t oken ( "extern  ")) 

5 

else  if  ( mat cht oken ( "register  ")) 

? 

else  ret  urn (FALSE) 


ret  urn (TRUE)  ; 


dclrt ion ()  /*  declaration  */ 

-C 

int  oldp=bufp,  linep-1  ine_.no ; 


if  (!typ_spf())  goto  quit; 

if  ( ! var _dec_l ist ( ) )        goto  quit; 
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if  (! match (';') )  goto  quit; 


return (TRUE) ; 
quit:    bufp=oldp;   1 ine_no=l inep;     nextch=buf Cbuf p] ; 
ret  urn  (FALSE)  -, 

> 


typ_spf ()  /*  type  specifier        */ 

-C 

if  (matchtokenC'char  ")) 

else  if  ( match to ken ( "short  ")) 

else  if  (matchtokenC'int  ")) 

5 

else  if  (matcht oken ( " long  ")) 

else  if  < match to ken < "unsigned  ")) 

else  if  (match token ("float  ")) 

5 

else  if  (matchtoken ( "double  ")) 

5 

else       return (FALSE) 


ret  urn (TRUE)  ; 


var_dec_l ist ( )        /*  variable  declaration  list  •*/ 
■C 

if  (IvardclrO)  ret  urn  (FALSE)  ; 

wh  i 1 e  ( morevardc 1 s ( ) ) 
5 

ret  urn (TRUE)  ; 
> 


morevardcls ( )  /*  more  variable  declarations    */ 

■C 

int  oldp=bufp,  1 inep=l ine_no ; 


if  (! match (',') )  goto  quit; 

if  (IvardclrO)  goto  quit; 
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return (TRUE) ; 
quit:    bufp=oldp;     1 i ne_no= 1 inep ;   next ch=buf Cbuf p] ; 

return (FALSE) ; 
> 


vardclrO  /*  variable  declaration  -*/ 

< 

int  oldp=bufp,  1 inep=l ine_no; 


if  (match  ('*')) 

■ 

if  (!id())  goto  quit; 

if (indxdclr () ) 

5 

if  ( in it ial izer ( ) ) 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     1 ine_no=l inep ;   nextch=buf Cbuf pi ; 
return (FALSE) ; 

> 


indxdclr  ()  /*  index  declaration  •*/ 

< 

int  oldp=bufp,      1 inep=l ine_no; 


if  (!  match  ('  C  )  >  goto  quit; 

if  (cnst _expr ( ) ) 

5 

if  (! match (']') )  goto  quit; 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf pD ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


initializer  ()  /*  initializer   •*/ 

int  oldp=bufp,  1 inep=l ine_no; 


if  (!  match  ('=')  )  goto  quit; 

if  (match  ( '  -C  '  )  ) 
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if  (! ex press ion () ) 
wh i le ( ! moreexpr ( ) ) 


if  (  !  match  ('>')) 


g  at  o  quit; 


goto  quit ; 


else  if  (! expression () )    goto  quit; 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;      1 ine_no=l inep ;   next ch=buf Cbuf pD ; 

ret  urn (FALSE)  ; 
> 


f unc_def ( ) 
■C 

int  oldp=bufp,  1 i nep=l ine_no ; 


/*  function  definition   ■*/ 


g 1 bpt r=buf p ; 

if  (typ_spf()) 

5 

if  ( ! f unc_dclr ( ) ) 

g 1 bptr=buf p ; 

if  ( ! func_body () ) 

f unc_end=TRUE ; 


goto  quit ; 


goto  quit  ; 


return (TRUE)  ; 
quit:       b u f  p=o 1 d  p ;     ne x  t  ch  =  b u f  C  b u f  p 1  ; 
ret  urn (FALSE)  ; 


1 ine_no=l inep ; 


f unc_dclr ( ) 

int  oldp=bufp,  1 inep=l ine_no; 


/*  function  declaration  */ 


if  (!id())  goto  quit; 

if  ( ! match ( ' ( ' ) )   goto  quit ; 

if  (idnfrs( ) ) 

5 

if  (! match (')') )   goto  quit; 
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return (TRUE) ; 
quit:       bufp=oldp;     nextch=buf Cbuf pD ; 
return (FALSE) ; 


1 ine_no=l inep ; 


idnf rs ( ) 


if  ( ! id () ) 

5 

while  (rnore_id()) 

■ 

return (TRUE) ; 


/*  identifiers   */ 


ret  urn (FALSE) 


rnore_id  (  ) 
■C 

int  oldp=bufp,  1 inep=l ine_no ; 


/*  more  identifiers 


*/ 


if  (  ! mat ch (','))   goto  quit; 

if  (!id())  goto  quit; 

ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch  =  buf Cbuf p3  ; 
return (FALSE) ; 


1 ine_no=l i  nep ; 


f unc_body ( ) 
■C 

int  oldp=bufp,  1 inep=l ine_no ; 


/*  function  body 


*/ 


if  ( ! type_dec_lst () ) 

g 1 bpt r=buf p ; 

if     (  !  crnpn_strnt  ( )  ) 


goto  quit ; 


goto  quit ; 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ; 
ret  urn (FALSE)  ; 


1 ine_no=l inep ; 
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type_dec_lst < ) 
■C 

int  oldp=bufp,  1 inep=l ine_no ; 


/*  type  declaration  list  */ 


if  (par_dclrtion() ) 

5 

while  ( par_dclrt ion ( ) ) 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;   1 ine_no=l inep ; 
return (FALSE) ; 

> 


nextch=buf Cbuf p3 ; 


par_dclrt ion ( )    /*  parameter  declarations  */ 
int  oldp=bufp,  1 inep=l ine_no; 


if  (!typ_spf()) 

if  ( ! par_dec_l ist ( ) ) 

if  (  !  match  ('  ;'  )  ) 


goto  quit 
goto  quit 
goto  quit 


return (TRUE) ; 
quit:   bufp=oldp;     1 ine_no=l inep ;    nextch=buf Cbuf p] ; 

ret  urn (FALSE)  ; 
> 


par_dec_l ist ( ) 
■C 


/*  parameter  declaration  list  */ 


if  (! parameter () )  ret  urn (FALSE) 

? 

while  (mor e par dels () ) 

■ 

ret  urn (TRUE)  ; 


morepardcls ( ) 
-C 

int  oldp=bufp,  1 inep=l ine_no ; 


/*  more  parameter  declarations   */ 


if  (! match (',') )   goto  quit; 
if  (! parameter () )  goto  quit; 
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return (TRUE) ; 
quit:     bufp=oldp;      1 ine_no=l inep ;  next ch=buf Cbuf pD ; 
return (FALSE) ; 

> 


parameter  ()  /*  parameter     -*/ 

■C 

int  oldp=bufp,  1 inep=l ine_no 5 

if  (match  ('*')) 

if  ( !  i d ( )  )  goto  quit; 

if  (indxdclr () ) 

ret  urn (TRUE)  ; 
quit:       bufp=oldp;     1 ine_no=l inep ;   next ch=buf Cbuf pD ; 
ret  urn (FALSE) ; 
> 


stmtO  /*  statement     */ 

■C 

i  f  (cmpn_strnt  ( )  ) 

else  if  (if_stmt ( ) ) 

■ 

else  if  (wh i le_stmt  ( )  ) 

5 

else  if  (do_stmt () ) 

? 

else    if     (for_strnt  ()  ) 

5 

else    if     (swtc_stmt ( ) ) 

• 

else  if  ( break_stmt ( ) ) 

else  if  (matchtoken ( "cont inue  ",1)) 

-C  if  (!  match  (';')  )  goto  quit; 

> 

else  if     (rtm_strnt  (  )  ) 

? 

else    if     (  goto_strnt  ( )  ) 

? 

else  if  ( f unc_cal 1 ( ) ) 

-C  if  (!  match  (';')  )  goto  quit; 

> 
else  if  (asnrntO) 


goto  quit  ; 


> 
else  if  (  label  ()  ) 


69 


else  if  ( mat  ch  ( '  ; '  ) ) 


else 
5 


quit  : 
> 


return (TRUE) ; 
ret  urn (FALSE)  ; 


goto    quit 


crnpn_strnt  ( ) 
•C 

int  oldp=bufp,  1 inep=l ine_no ; 


/*  compound  statement    */ 


quit  : 
> 


if  (  !  match  ( '  -C  '  )  ) 

while  (dclrt ion ( ) ) 

5 

if  (1st  mt ( )  ) 

while  (stmt ( ) ) 

if  (  !  match  ('>')) 

ret  urn (TRUE)  ; 
buf p=oldp; 
return (FALSE)  ; 


goto  quit  ; 


goto  quit ; 


goto  quit ; 
nextch=buf Cbuf pD ; 


1 ine_no=l inep; 


func_call()  /*  function  call 

■C 

int  oldp=bufp,  1 inep=l ine_no ; 


*/ 


if  (  ! id()  ) 

if  (  !  match  ('  ('  )  ) 

i  f  (expr_lst  ( )  ) 

if  (  ! match  (')')) 


goto  quit  ; 
goto  quit  ; 

goto  quit ; 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf pJ ; 
ret  urn (FALSE)  ; 


1 ine_no=l inep ; 
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expr_lst()  /*  expression  list       */ 

■C 

if  (! expression () )         return (FALSE J 

while  (moreexpr () ) 

ret  urn (TRUE)  ; 
> 


moreexpr ()  /*  more  expressions      */ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 


if  (! match (',') )  goto  quit; 

if  (! expression () )  goto  quit; 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf pD ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


asnmt ( )  /*  assignment  statement  */ 

i  f  (assi  gn ( )  ) 

■ 

else  if  (  i ncr _strnt  ( )  ) 

? 

else       ret  urn (FALSE) 


ret  urn (TRUE)  ; 

> 


assign  ()  /*  simple  assignment     •*/ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 


if  (!lvalue())  goto  quit; 

if  (match  ('=')) 

•C  if  (  !  1  gc_expr  ( )  )  goto  quit; 

> 
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else  if  (shf  _asrn_op  (  )  ) 

-C   if  (  !shf_expr  ( )  ) 

> 

else  if  (btw_asm_op() ) 

<        if  ( ! btw_expr() ) 

> 

else 


goto  quit  ; 

goto  quit ; 
goto  quit 


return (TRUE) ; 
quit:    bufp=oldp;     next ch=buf Cbuf pD ; 
ret  urn (FALSE)  ; 

> 


1 ine_no=l inep ; 


shf _asm_op ( ) 
■C 


if  (match to ken ( "+= 


/*    shift  assignment  operator 


,  1Z1)  ) 


*/ 


else  if  (matchtoken  <  "-=  ",iZ»)) 

? 

else  if  (matchtoken ( "*=  ",0)) 

? 

else  if  (matchtoken  ("/=  ",iZi>) 

m 

i 

else  if  (matchtoken  ("•/•=  ",iZD) 

5 

else  if  (matchtoken  (">  )=  ",(ZD) 


else  if  (matchtoken (" < (=  ",iZD) 

■ 


else 


return (FALSE) 


ret  urn (TRUE)  ; 


bt w_asm_op ( ) 


/*  bitwise  assignment  operator   ■*/ 


if  (matchtoken  ("&=  ",iZD) 
else  if  (matchtoken  ("■-=    ",iZD) 
else  if  (matchtoken <" I =  ",id)) 
else  return (FALSE) 

return (TRUE) ; 
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incr_stmt ( ) 
-C 

int 
char 


/*  incremental  statement*/ 


oldp=bufp,  1 inep=l ine_no ; 

pre_op=TRUE;  /*  pre-operator  */ 


if  (match to ken ( "++  ",0)) 

? 

else  if  (match token ( " —  ",0)) 

! 

else 

■ 

if  (  !  lvalueO  ) 


pre_op=FALSE 


goto  quit ; 


if  ( ! pre_op) 
< 

if  (match token ( "++  ",0)) 

m 

i 

else  if  (matchtokenC —  ",iZD) 

5 

else 


goto  quit ; 


quit  : 
> 


ret  urn (TRUE)  ; 

bufp=oldp;     next ch=buf Cbuf pD ; 

return (FALSE)  ; 


1 ine_no=l inep ; 


if_strnt  () 


/*  if  statement 


*/ 


if  (! match token (" if  ",!))  goto  quit 


if  (  !  match  ('  ('  )  ) 

if  ( ! lgc_expr ( ) ) 

if  ( ! match (')')) 

if  (IstrntO) 

if  (else_stmt  ()  ) 

ret  urn (TRUE)  ; 

quit:  return (FALSE) ; 

> 


goto  quit 
goto  quit 
goto  quit 
goto  quit 
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else_stmt  ( ) 
■C 


/*  else  statement 


*/ 


if  (! match token ("else  ",1)) 
if  (IstmtO) 


goto  quit ; 
goto  quit ; 


quit  : 
> 


return (TRUE) ; 
ret  urn (FALSE)  ; 


wh  i le_stmt ( ) 
■C 


/*  while  statement 


*/ 


if  (! match token ( "while  ",!>) 

if  (  !  match  ('  ('  )  ) 

if  ( ! 1 gc_expr ( ) ) 

if  (  !  match  (MM) 

if  (IstmtO) 

return (TRUE) ; 

quit:  ret  urn (FALSE)  ; 
> 


goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 


do_stmt ( ) 
■C 


/*    do    statement 


*/ 


if  (  ImatchtokenC'do    ",1)) 

if  ( istmt () ) 

if  (  Irnatchtoker.  (  "while    ",D) 

if  (  ! match  ('  (M  ) 

if  ( ! 1 gc_expr ( ) ) 

if  (  !  match  (MM) 

if  (  !  match  ('  ;M  ) 


goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 


quit  : 
> 


return (TRUE) ; 
ret  urn (FALSE)  ; 
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f  or_st  rnt  ( ) 
■C 


/*  for  statement 


if  (! match token ("for  ",1)) 

if  (  !  match  ('  ('  )  ) 

if  (asn_lst  () ) 

if  (  !  match  (';')) 

if  ( ! 1 gc_expr ( ) ) 

if  (  !  match  (';')) 

if  (asn_lst  ()  ) 

5 

if  (  !  match  (MM) 

if  ( ! stmt ( ) ) 


*/ 

goto  quit ; 
goto  quit ; 


goto  quit 
goto  quit 
goto  quit 

goto  quit ; 

goto  quit ; 


quit  : 
> 


return (TRUE) ; 
ret  urn (FALSE)  ; 


asn_lst ( ) 
-C 


/■*  assignment  list 


if  ( ! asnmt ( ) ) 

5 

while  (more_asnmt ( ) ) 

a 

ret  urn (TRUE)  ; 


return (FALSE) 


*/ 


/*  more  assignments 


more_asnmt ( ) 
-C 

int  oldp=bufp,  1 inep=l ine_no ; 


*/ 


if     ( ! match (','>> 
if     (  !  asnrnt  ( )  ) 


goto    quit ; 
goto    quit ; 


quit  : 

> 


ret  urn (TRUE)  ; 

bufp=oldp;     nextch=buf Cbuf pD ; 

ret  urn (FALSE)  ; 


1 ine_no=l inep ; 


75 


swtc_stmt  ( ) 
■C 


/*  switch  statement 


*/ 


if  <! match token <" switch  ",!)) 

if  (  !  match  ('  ('  )  ) 

if  ( ! art _expr ( ) ) 

if  ( ! match (')')) 

if  ( (match ('<')) 

if  ( !case_stmt () ) 

while  (case_stmt ( ) ) 

5 

if  (  !  match  ('>')) 


goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 
goto  quit 

goto  qui t  ; 


quit  : 
> 


ret  urn (TRUE)  ; 
ret  urn (FALSE)  ; 


case_stmt ( ) 
■C 


/*  case  statement 


*/ 


if  (matcht oken ( "case  ",1)) 

■C  if  (  !  cnst _expr  ( )  ) 

> 

else  if  (rnatchtoken  ( "default  ",iZD) 


else 
5 

if  (  !  match  (':')) 

wh  i le  (stmt ( ) ) 
? 

return (TRUE) ; 
quit:    ret  urn (FALSE)  ; 
> 


goto  quit ; 

goto  quit 
goto  quit ; 


break_stmt ( ) 

-C 


/*  break  statement 


*/ 


if     (!  rnatchtoken  ("break    ",D) 
if     (  !  match  (';')) 


goto  quit ; 
goto  quit  ; 
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return (TRUE) ; 
quit:  return (FALSE) ; 

> 


rtrn_strnt<)  /*    return    statement  */ 

if     (! match token ( "ret  urn    ",1))  goto    quit; 

if     (expression () ) 

! 

if  ( ! match ( ' ; ' ) )  goto  quit ; 


ret  urn (TRUE)  ; 
quit:    return (FALSE) ; 

> 


goto_stmt()             /*  goto  statement  •*/ 
■C 

if  (! match token ( "goto  " , 1 ) )         goto  quit; 

if  (!id())                           goto  quit; 

if  ( ! match (';'))                    goto  quit; 


return (TRUE) ; 
quit:    ret  urn (FALSE)  ; 
> 


label ()  /*  label  */ 

-C 

int  oldp=bufp,  1 inep=l ine_no ; 


i  f  (  !  i  d  ( ) )  goto  quit; 

if  ( ! match (':'))  goto  quit ; 


ret  urn (TRUE)  ; 
quit:       bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 
ret  urn (FALSE)  ; 

> 
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expression ( )  /*  expression    */ 

■C 

if  (string  <) ) 

5 

else  if  ( pntr_expr ( ) ) 

5 

else  if  (addr_expr ( ) ) 

5 

else  if  (lgc_expr()) 

■ 

else  if  (  incr_st rnt  ( )  ) 

5 

else       return (FALSE) 

• 

ret  urn (TRUE)  ; 


pntr_expr()  /*  pointer  expression    */ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 


if     (!  match  ('*')  )  goto    quit; 

if     (array_elrn  (  )  ) 

else  if  (id  () ) 

5 

else  if  (match  ('  ('  )  ) 
-C 

if  ( ! art_expr ( ) )  goto  quit; 

if  ( ! match (')'))  goto  quit ; 

> 
else  goto  quit 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf pD ;         1 ine_no=l inep ; 
ret  urn (FALSE)  ; 

> 


addr_expr()  /*  address  expression    */ 

-C 

int  oldp=bufp,  1 inep=l ine_no; 
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if  (  !  match  ('&•')) 

i  f  ( array _elrn  ( )  ) 

5 

else  if  (idO) 

! 

else 

* 


goto  quit 


goto  quit 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ; 

ret  urn (FALSE)  ; 
> 


1 ine_no=l inep ; 


1 gc_expr ( ) 
-C 


/*  logic  expression 


*/ 


if  (  !  lgc_trrn()  ) 

■ 

while  (lg_trms()) 


ret  urn ( FALSE ) 


ret  urn (TRUE)  ; 


lg_trrns()  /*  logic  terms 

int  oldp=bufp,  1 inep=l ine_no; 


*/ 


if  (!  match  token  ("  I  I  ",iZD)  goto  quit; 
if  (!lgc_trm())  goto  quit; 


return (TRUE) ; 
quit:    b  u  f  p=o 1 d  p ;     ne  x  t  ch  =  b  u  f  C  b  u  f  p 1 ; 
ret  urn (FALSE)  ; 

> 


1 ine_no=l inep ; 


1  gc_t  rrn  (  ) 

■C 


/*  logic  term 


*/ 


if  (!lgc_fct()) 
while  (lg_fcts()) 

■ 
1 

ret  urn (TRUE)  ; 


ret  urn (FALSE) 
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lg_fcts()  /*  logic  factors         */ 

•C 

int  oldp=bufp,  1 inep=l ine_no ; 


if  (! match token ("&&  ",8))  goto  quit; 
if  (!lgc_fct<))  goto  quit; 

return (TRUE) ; 
quit:    bufp=oldp;     next ch  =  buf Cbuf pD  ;         1 ine_no=l inep ; 

ret  urn  (FALSE)  ; 
> 


lgc_fct()  /*  logic  factor  */ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 

if  (  match  ('  !'))  /*  unary  operator        •*/ 

5 

i  f  <  btw_expr ( )  ) 

■ 

else  if  (match  ('  ('  )  ) 
■C 

if  ( ! 1 gc_expr ( ) )  goto  quit; 

if  ( ! match (')'))  goto  quit ; 

> 
else  goto  quit 


return (TRUE) ; 
quit:    bufp=oldp;     nextch  =  buf  Cbuf  pD  ;        1  ine_.no—  1  inep; 

ret  urn (FALSE)  ; 
> 


btw_expr()  /*  bitwise  expression    */ 

■C 

int  oldp=bufp,  1  inep—  1  ine_.no ; 

if     (match  ('**')) 

i 

if     (  !  btw_trrn  ( )  )  goto    quit; 

while     (bt_trms()) 

i 

ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 
ret  urn (FALSE)  ; 

> 
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bt_trms()  /*    bitwise    terms  */ 

■C 

mt    oldp=bufp,     linep=line_rio; 


if  ( ! match ( ' I ' ) )  goto  quit ; 

if  (!btw_trm())  goto  quit; 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf pi ;         1 ine_no=l inep ; 

return (FALSE) ; 
> 


btw_trm()  /*  bitwise  term  */ 

■C 

if  <!btw_fct()>  ret  urn (FALSE) 

■ 

whi  le  (bt  fctsO  ) 


ret  urn (TRUE)  ; 

> 


bt_fcts()  /*  bitwise  factors       */ 

■C 

int  oldp=bufp,  1 inep=l ine_no ; 


if  (!  match  ('""•')  )  goto  quit; 

if  (!btw_fct())  goto  quit; 

ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


btw_fct<)  /*  bitwise  factor        */ 

■C 

if  (!btw_elm())  ret  urn (FALSE) 

wh  i le  (bt  elms ( )  ) 


ret  urn (TRUE)  ; 

> 
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bt_elrns()  /*  bitwise  elements      */ 

■C 

int  oldp=bufp,  1  inep=l ine_no; 


if  (!  match  ('&')  >  goto  quit; 

if  <!btw_elm<))  goto  quit; 


return (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 

return (FALSE) ; 
> 


btw_elrn<)  /*    bitwise    element  */ 

■C 

int  oldp=bufp,  1 inep=l ine_no ; 

i  f  (cmp_expr ( )  ) 

5 

else  if  (match ('  ('  ) ) 
-C 

if  ( ! btw_expr ( ) )  goto  quit; 

if  (  ! mat ch ( '  ) '  )  )  got o  quit ; 

> 
else  goto  quit 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf p] ;         1 ine_no=l inep ; 
return (FALSE) ; 

> 


cmp_expr()  /*  compound  expression   */ 

-C 

int  oldp=bufp,  1 inep=l ine_no; 


if     (  !  cmp_t  rrn  ( )  )  ret  urn  (FALSE) 

■ 

i 

while     (cp_trms()) 


ret  urn (TRUE)  ; 


> 
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cp_trms()  /*  compound  terms        */ 

■C 

int  oldp=buf p,  1 inep=l ine_no ; 

if  ( ! equ_op ( ) )  goto  quit ; 

if  (  !  crnp_trm  ( )  )  goto  quit; 


return (TRUE) ; 
quit:  bufp=oldp;       nextch=buf Cbuf pH ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


equ_op()  /*  equality  operators     ■*/ 

-C 


if  (rnatchtoken("==  ",iZD) 


i 


else  if  (matchtokenC  !  =  ",0)) 

5 

else       .ret  urn (FALSE) 


ret  urn (TRUE)  ; 


> 


cmp_trrn()       /*  compound  term         */ 
< 

if  (  !crnp_fct  ()  )  ret  urn  (FALSE) 

■ 

while  (cp_fcts<)) 


ret  urn (TRUE)  ; 
> 


cp_fcts()  /*  compound  factors      */ 

if  (!rel_op())  goto  quit; 

if  ( ! cmp_fct ( ) )  goto  quit; 


return (TRUE) ; 
quit:    ret  urn (FALSE)  ; 

> 
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rel_op<)  /*  relational  operator   */ 

■C 

if  (match  ('  <'  )  ) 

<  if  (match  ('=')); 

> 

else  if  (match (' > ' ) ) 

-C  if  (match  ('=')); 

> 

else       return (FALSE) 

■ 

i 

ret  urn (TRUE)  : 


cmp_fct()  /*  compound  factor       ■*/ 

-C 

int  oldp=bufp,  1 inep=l ine_no; 


if  (shf_expr()) 

■ 

else  if  (match  ('  ('  )  ) 

if  (  !  crnp_expr  ( )  )  goto  quit; 

if  (!  match  (MM  )  goto  quit; 

> 
else  goto  quit 


return (TRUE)  ; 
quit:    bufp=oldp;     nextch  =  buf Cbuf pD  ;         1  ine_no=l inep ; 
return (FALSE) ; 

> 


shf_expr()  /*  shift  expression      ■*/ 

-C 

int  oldp=bufp,  1 inep=l ine_no ; 

if  (shf_init () ) 

5 

if  ( ! art_expr ( ) )  goto  quit 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 
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shf_init()  /*  shift  expression-initial      •*/ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 


if  (llvalueO  )  goto  quit; 

if  (!shf_op())  goto  quit; 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf pi ;         1 ine_no=l inep ; 

return (FALSE) ; 
> 


shf_op()  /*  shift  operator        */ 

■C 

if  (matchtoken<"> >  ",0>) 

■ 

else    if     (rnatchtokenC  <  <     ",iZD) 

? 

else       ret  urn (FALSE) 


return (TRUE) ; 
> 


art_expr()  /*  arithmetic  expression  -*/ 

■C 

int  oldp=bufp,  1 inep=l ine_no ; 

if  (match  ('-')  )  /*  unary  operator        ■*/ 

if  (!term())  goto  quit; 

while  ( more_t  erm ( )  ) 

ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p] ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


rnore_terrn  ( )  /*    more    terms  */ 

■C 

if  ( ! add_op ( ) )  goto  quit; 

if  (!term())  goto  quit; 
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return (TRUE) ; 
quit:    return (FALSE) 5 
> 


add_op ( ) 
■C 


/*  additional  operator   */ 


if  (match  ('+'  )  ) 


else  if  (match  ('-')  ) 


else 


ret  urn (FALSE) 


ret  urn (TRUE)  ; 


term ( ) 


if  (! factor <)) 


/*  term 


return (FALSE) 


*/ 


while  (rnore_f  cts  ( )  ) 

■ 

ret  urn (TRUE)  ; 


/*  more  factors  •*/ 


more_f ct s ( ) 
■C 

int  oldp=bufp,  1 inep=l ine_no; 


if  ( !mul_op() ) 
if  (IfactorO) 


goto  quit  ; 
goto  quit  5 


return (TRUE) ; 
quit:    bufp=oldp;     nextch=buf Cbuf pD ; 

ret  urn (FALSE)  ; 
> 


1 ine_no=l inep ; 


mul_op  < ) 
■C 

if  (match  ('*')) 


/*  rnult  i  pi  icat  ional  operator     */ 


else  if  (match (' /' ) ) 
5 
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else  if  (match  ('  ■/.'  )  ) 
else       ret  urn (FALSE) 


ret  urn (TRUE)  ; 


factor ()  /*  factor        */ 

■C 

int  oldp=bufp,  1 inep=l ine_no; 


if  (match  ('  ('  )  ) 
■C 

if  ( ! art_expr ( ) )  goto  quit; 

if  (! match  (')')  )  goto  quit; 

> 
else  if  ( f unc_cal  1  (  )  ) 

? 

else  if  (cnst_expr ( ) ) 

5 

else  if  (char_def ( ) ) 

5 

else    if     (  i ncr _strnt  ( )  ) 

■ 

else  if  ( lvalue  <) ) 

* 

else  goto  quit 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 

ret  urn (FALSE)  ; 
> 


cnst_expr()  /*•  constant  expression   ■*/ 

■C 

i  f  (  const  ant ( ) ) 

5 

else  if  ( !cnst_id ( ) ) 

ret  urn (FALSE)  ; 


ret  urn (TRUE)  ; 
> 
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lvalue ()  /*    left    value  */ 

■C 

int  oldp=bufp,     1 inep=l ine_no; 

char  pmthsis=FALSE ; 


if     (match  (MM)  pmthsis=TRUE; 

if     ( array _e  1  rn  ()  ) 

else  if  (id  () ) 

? 

else  if  ( pntr_expr ( ) ) 

? 

else         .  goto  quit 


if  (pmthsis) 

if  (! match ( M  M )  goto  quit; 

ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf p3 ;         1 ine_no=l inep ; 
return (FALSE) ; 

> 


array_elm()  /*  array  element         ■*/ 

int  oldp=bufp,  1 inep=l ine_no; 


if  (!id())  goto  quit; 

if  (! index ())  goto  quit ; 


ret  urn (TRUE)  ; 
quit:    bufp=oldp;     nextch=buf Cbuf pD ;         1 ine_no=l inep ; 

return (FALSE) ; 
> 


index ()  /*  index  expression  for  arrays   */ 

■C 

int  oldp=bufp,      1 inep=l ine_no; 


if  (!  match  (MM)  goto  quit; 

i  f  (art _expr ( ) ) 

5 

if  (!  match  (MM)  goto  quit; 
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quit  : 

> 


ret urn (TRUE) ; 

bufp=oldp;     nextch=buf Cbuf pD ; 
return (FALSE) ; 


1 ine_no=l inep ; 


primary ( ) 
•C 


/*  primary  expression    */ 


i  f  (cnst_expr ( )  ) 
else  if  ( arr ay _e  1  rn  ()  ) 
else  if  (id  ( )  ) 

lse  if  (char_def () ) 
else  if  (string ()) 
else       ret  urn (FALSE) 

return (TRUE) ; 
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APPENDIX  C 


TERMINALS  AND  BASIC  NONTERMINALS 


isaltr(c)        /*  is  a  letter?  */ 

int      c;       /*  character  to  test     •*/ 
■C 

return  ((  c>  =' A'  &&  c<  =  'Z'  )   II   (  c>  =' a'  &•&  c<  =  'z'  )); 
> 


iscapch (c) 
int  c; 
< 

return  (  c>='A'  &&  c<  =  'Z'  ); 
> 


/*  is  a  capital  letter?      */ 
/*  character  to  test  */ 


isadgt (c) 
int  c 


/*    is    a    digit?  #/ 

/*    chAt^dLcter    to    test  •*/ 


return     (    c>  =' 0'     &•&    c  <  =  ' 9'     ); 


isidch(c)        /*  is  identifier  character?  */ 

int     c ; 

-C 

ret  urn (  isaltr(c)   II  isadgt  (c)   II  c==' _'  ); 
> 


del i miter  < ) 


/*  is  next-character  a  delimiter? 


*/ 


ret  urn (  nextch== 

'  =' 

nextch== 

'  <'   i 

1   nextch== 

'  >  '    II 

nextch== 

'  +  '   1 

nextch== 

i  _*   | 

1   nextch== 

'  1  '    II 

nextch== 

'  •*'   | 

nextch== 

■  /'   i 

1   nextch== 

'  &'    II 

next ch== 

i  ■  i      i 

»    ■ 

nextch== 

i        ■ 

1   nextch== 

i  ■  i    II 

next ch== 

'  )  '   1 

nextch== 

i  ••••1   | 

1   nextch== 

i  ii    || 

next ch== 

'  %'   1 

nextch== 

'  c   i 

1   nextch== 

'  )  '    II 

nextch== 

'  C   1 

next ch== 

'  3'   1 

1   nextch==' 

i            |  | 

whtchr (nextch ) 

) ; 

whtchr (c) 
int      c ; 
■C 

return  (  c=='  '   I  I  c==TAB 
> 


/*  is  a  white-character? 
/#  character  to  test 


c==CR 


*/ 
*/ 

c==LF  ) ; 
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char_def ()        /*  is  character  definition?  ■*/ 
■C 

char     blank=FALSE;  /*  boolean  war.     for  blanks  */ 

delwht();  /*  skip  white  characters    -*/ 

/*  character  definition  should  start  with  "'  "  character     ■*/ 
if  (! match ('  \'  ')  )         ret  urn (FALSE ) 
5 

/*  consume  the  following  white  characters,  if  there  is  any   -*/ 

while  (  wht chr (next ch )  ) 
-C 

nextch  =  getchrO  ; 

blank  =  TRUE; 

> 


if  (  nextch=='  \'  '  ) 
•C 
/*  check  if  character  body  is  empty      */ 

if  (  'blank  ) 
/*  illegal  character  definition  */   err_msg ( ICDF) 
5 

/*  else  it  is  a  blank  character  ■*/ 
else 
< 

nextch=getchr ( ) ; 
ret  urn (TRUE)  ; 
> 
> 

/*  if  met  '  V  character,  parse  one  more  */ 
if  (  nextch==' W  )       nextch=get chr ( ) 


/*  parse  the  original  character  ■*/ 
next ch=getchr ( ) ; 


/*  should  finish  with  '""  character!     */ 

if  (  !  match  ('  \'  '  )  ) 
/*  illegal  character  definition  */   err_msg ( ICDF) 

i 

ret  urn (TRUE)  ; 

> 
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string ()  /*  is  string?  */ 
■C 

char     i;  /*  index  variable        */ 

delwhtO;  /*  skip  white  characters     */ 


/*  string  mast  start  with  '"'  character  */ 
if  (!  match  ('"')  )         ret  urn  (FALSE) 


/*  since  strings  not  implemented  in  Tiny— C,  just  consume  it  */ 

for  <i=tZi;  (  nextch!='"')  &•&•  (  i  <=MXSTR  );  ++i  ) 
nextch=getchr ( ) ; 


/*  check  if  it  is  too  long   -*/ 

if  (  i  >  MXSTR  ) 
/*  string  length  too  long   */    err_msg (SLTL) 

i 

/*  should  finish  with  '  '"  character  */ 
match ('"'); 

ret  urn (TRUE)  ; 
> 


constant  ()   /*  integer  constant  •*/ 
■C 

char     i=iZi;  /*  index  variable        */ 

delwht();  /*  skip  white  characters     */ 

/*  it  should  start  with  a  digit      */ 

if  (  !  isadgt (nextch) )     ret  urn (FALSE) 


while  ( isadgt (nextch ) )        /*  parse  the  number  */ 
{ 

/*  check  if  number  length  is  too  long    ■*/ 

if  (i>=MXNML) 
/*  number  length  too  long    ■*/   err_msg  (NLTL) 

5 

else  num  name C i++D =nextch 


nextch=getchr ( )  ; 

> 

if     (nextch !='     '     &•&     !  delimiter  < )     ) 

/*    delimiter    was    expected  */  err_msg  (DWEX ) 

5 

num_narne  C  i  3  ='     '  ; 

/*  convert  string  "num_name"  into  numeric  value  */ 
str_num  < )  ; 

/*  add  number  into  constant  table    */ 
add_num ( ) ; 

ret  urn (TRUE)  ; 

> 


cnst_id()    /*  constant  identifier   -*/ 
■C 

int  oldp,    1 inep; 

char     i=iZi;  /*  index  variable        •*/ 

del'whtO;  /*■  skip  white  characters     */ 

oldp=bufp;   1 inep=l ine_no ; 
next ch=buf Cbuf pD ; 


/*  first  character  should  be  a  capital  letter    ■*/ 
if  (  !  iscapch (nextch)  )         ret  urn (FALSE) 

while  ( iscapch (nextch) ) 

/*  check  if  identifier  length  is  too  long    ■*/ 

if  (i>=MXIDL) 
/*    identifier  length  too  long    •*/   warning  (I  LTD 

5 

else  id  name C i++3 =next ch 


next ch=getchr ( ) ; 

> 

/*  if  following  character  is  still  a  letter,  it  can    be  a  lower 
letter  only,  since  Tiny-C  assumes  constant  identifiers  are 
all  capital  letters,  this  cannot  be  a  constant  identifier  */ 
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if  ( isalt r (nextch ) )       goto  quit 


if  (nextch !='  '  &&  ! del i miter ( )  ) 
/*  delimiter  was  expected    */    err_msg (DWEX ) 


ret  urn (TRUE)  ; 

/*  backtrack  on  the  scanner  buffer,  and  return  FALSE     -*/ 

quit:    bufp=oldp;      1 ine_no=l inep ;     nextch=buf Cbuf p3 ; 

ret  urn (FALSE)  ; 
> 


id()          /*  is  identifier?    */ 
■C 

char     i=0;  /*  index  variable        */ 

delwhtO;  /*  skip  white  characters     */ 


/*  should  start  with  a  letter   */ 

if  (!  isalt r (nextch)  )  ret  urn (FALSE) 


while  ( isidch (nextch ) ) 
•C 

/*  check  if  identifier  length  is  too  long    */ 

if  (i>=MXIDL) 
/*  identifier  length  too  long    */   warning ( I LTD 

? 

else  id  narneC  i++D  =nextch 


nextch=getchr ( ) ; 
> 

/*  following  character  must  be  a  delimiter!  */ 

if  (nextch  !='  '  &•&•  !  delimiter  <)  ) 

/*  delimiter  was  expected    •*/    err_msg  (DWEX ) 

i 

id_name  C  i 1 ='  '  ; 
/*  if  identifier  is  a  reserved  word,  give  error  message  */ 
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if  ( !rsvr_test () ) 
/*  reserved  word  not  expected    ■*/   err_msg ( RVNE) 
? 

ret  urn (TRUE)  ; 


APPENDIX  D 


TINY-C  COMPILER  ERROR  AND  WARNING  MESSAGES 


Error  Messages 


#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
ttdefine 
#def ine 
ttdefine 
#def ine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 
ttdefine 


AVNI 
SVNI 
EVNI 
RVNI 
SMEX 
LINI 
UINI 
FPNI 
DPNI 
IDEX 
IBSB 
RSBE 
CINI 
EXEX 
LCBE 
LPEX 
RPEX 
IEAC 
EEAC 
PTNI 
ARNI 
IPNI 
FTEX 
IVFD 
RCBE 
PREX 
PREC 
AEAC 
LPEI 
LPEW 
LPEF 
LPES 
ILEI 
I  LEW 
ILEF 
WMFD 
SSFI 
SSFE 
SSFW 
SSFF 
SSFD 
SMIF 
IAES 
CSMS 
CLIM 


a 
6 
7 

a 

9 

10 

u 

12 
14 
15 
IS 
17 
18 
19 
£0 
£1 


£6 
£7 
£8 
£9 
30 
31 
41 


34 
35 
36 
37 
38 
39 
54 
40 
4£ 
43 
44 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


auto  variables  not  implemented  */ 

static  variables  not  implemented  -*/ 

external  variables  not  implemented  -*/ 

register  variables  not  implemented  */ 

semicolon  was  expected  */ 

long  integers  not  implemented  */ 

unsigned  integers  not  implemented  */ 

floating  points  not  implemented  */ 

double  precisions  not  implemented  */ 

identifier  was  expected  */ 

index  body  was  supposed  to  be  blank  */ 

right  square  bracket  was  expected  */ 
compound  initializers  not  implemented*/ 

expression  was  expected  */ 

left  curly  bracket  was  expected  */ 

left  parenthesis  was  expected  */ 

right  parenthesis  was  expected  */ 

identifier  was  expected  after  comma  */ 

expression  was  expected  after  comma  */ 

pointers  not  implemented  */ 

arrays  not  implemented                ■  */ 

include  preprecsr  not  implemented  */ 

filetype  was  expected  */ 

invalid  file  definition  */ 

right  curly  bracket  was  expected  */ 

parameter  was  expected  */ 

parameter  expected  after  comma  */ 

an  assignment  expected  after  comma  */ 

left  parenthesis  expected  after  if  */ 

left  prnthsis.  expected  after  while  */ 

left  parenthesis  expected  after  for  */ 
left  pmthesis.  expected  after  switch*/ 

illegal  logic  expression  in  if  */ 

illegal  logic  expression  in  while  */ 

illegal  logic  expression  in  for  */ 

while  is  missing  from  do  */ 

a  statement  should  follow  after  if  */ 

a  statement  should  follow  after  else  */ 
a  statement  should  follow  after  while*/ 

a  statement  should  follow  after  for  */ 

a  statement  should  follow  after  do  */ 

semicolon  is  missing  in  for  */ 

illegal  arith.  expression  in  switch  */ 

case  statement  is  missing  */ 

colon  is  missing  */ 
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#def ine 

ICEC 

45 

ttdefine 

ftENI 

46 

#def i  ne 

OCNI 

47 

#def ine 

BON  I 

48 

#def ine 

SENI 

49 

ttdefine 

INPE 

50 

#def i  ne 

INftE 

51 

#def ine 

UNVR 

52 

ttdefine 

IflEI 

53 

ttdefine 

RVNE 

56 

ttdef i  ne 

ILFB 

57 

ttdefine 

CBPR 

58 

ttdefine 

TBBP 

59 

ttdef i  ne 

UEOF 

60 

ttdefine 

CETL 

61 

ttdefine 

SETL 

62 

ttdefine 

UMPH 

63 

ttdefine 

SMUP 

64 

ttdef 1 ne 

CIEX 

65 

ttdefine 

CVEX 

66 

ttdef i  ne 

STIF 

67 

ttdefine 

NLTL 

68 

ttdefine 

TBNV 

69 

ttdefine 

NSIF 

70 

ttdefine 

DTIF 

71 

ttdefine 

CTIF 

72 

ttdefine 

VSIF 

73 

ttdefine 

LTIF 

74 

ttdefine 

DC  ID 

75 

ttdefine 

DLDC 

76 

ttdefine 

ICDF 

77 

ttdefine 

SLTL 

78 

ttdefine 

DWEX 

79 

ttdefine 

UDLB 

80 

ttdefine 

DPDC 

81 

ttdefine 

DPFft 

82 

ttdefine 

UNPE 

83 

ttdef  ine 

DFDC 

84 

ttdef i  ne 

I  CAN 

86 

ttdefine 

DDDC 

87 

ttdefine 

IVBR 

88 

ttdefine 

TMNL 

89 

/*  invalid  constant  exprs.  after  case  -*/ 

/*  address  expression  not  implemented  ■*/ 

/*  one' s  complement  not  implemented  */ 

/*    bitwise  operators  not  implemented  •*/ 

/*  shift  expressions  not  implemented  */ 

/*  invalid  pointer  expression  */ 

/*  invalid  address  expression  */ 

/*  unknown  variable  -*/ 
/*  invalid  arith.  expr.  in  array  index   */ 

/*  reserved  word  not  expected  */ 

/*  illegal  function  body  */ 

/*  input  couldn' t  be  parsed  */ 

/*  too  big  block  to  parse  */ 

/*  unexpected  end  offile  */ 

/*  comment  endless  or  too  long  */ 

/*  string  is  endless  or  too  long  -*/ 

/*  unmatched  parenthesis  */ 
/*  semicolon  missing/unmatched  pmt  hesi  s*V 

/*  constant  identifier  expected  -*/ 

/*  constant  value  expected  *■/ 

/*  symbol  table  is  full  */ 

/*  numeric  length  too  long  ■*/ 

/*  too  big  numeric  value  •*/ 

/*  name  string  is  full  •*•/ 

/*  definition  table  is  full  -*/ 

/*  constant  table  is  full  -*/ 

/*  variable  string  is  full  ■*/ 

/*  label  table  is  full  */ 

/•*  duplicated  cons,  id  declaration  */ 

/*  duplicated  label  declaration  */ 

/*  illegal  character  definition  */ 

/*  string  length  too  long  */ 

/*  delimiter  was  expected  ■*/ 

/*  undeclared  label  •*/ 

/*  duplicated  parameter  declaration  •*/ 
/*  declared  parameter  is  not  a  fun.  arg.*/ 

/*  undeclared  parameter  exists  */ 

/*  duplicated  function  declaration  */ 

/*  inconsistent  argument  number  */ 

/*  duplicated  default  declaration  */ 

/*  invalid  break  usage  */ 

/*  too  many  nested  level  ■*/ 


Uaminq  Messages 


ttdefine  AFRI 

ttdefine  CSIB 

ttdefine  ILTL 

ttdefine  TOMF 


/*  all  functions  return  integer  ■*/ 

/*  compound  statement  is  blank  •*/ 

/*  identifier  length  too  long  */ 

/*  main  function  is  missing  ■*/ 
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APPENDIX  E 


INTERMEDIATE  CODE  DEFINITIONS  FOR  TINY-C 


ttdefine 

IftDD 

1 

#def ine 

I  SUB 

c 

ttdefine 

IMUL 

o 

#def ine 

IDIV 

4 

ttdefine 

MDLS 

5 

#def ine 

I  MLB 

6 

#def ine 

JUMP 

7 

#def ine 

JPTR 

8 

#def ine 

JPFL 

9 

#def ine 

LGEX 

10 

ttdefine 

CONS 

11 

ttdef ine 

ARID 

12 

#def ine 

VftRB 

13 

#def ine 

UNMS 

14 

ttdef ine 

LGNT 

15 

#def ine 

EQLT 

18 

ttdef ine 

NTEQ 

IS 

#def ine 

LSTN 

£0 

#def ine 

GRTN 

£1 

ttdef  i  ne 

LTEQ 

cc 

#def ine 

GTEQ 

Cy 

#def ine 

LGftN 

£4 

ttdef ine 

LGOR 

£5 

ttdef ine 

ftSSN 

£6 

ttdef ine 

PDAS 

£7 

#def ine 

SBP1S 

£8 

ttdef ine 

MLAS 

£9 

#def ine 

DVftS 

30 

#def ine 

MDflS 

31 

ttdef ine 

FNCL 

uC 

ttdef i ne 

ARGM 

33 

ttdef ine 

EXLB 

34 

ttdef ine 

GOTO 

35 

#def ine 

CASE 

36 

ttdef ine 

TVAR 

37 

ttdef ine 

SWTC 

38 

ttdef ine 

PNTR 

39 

ttdef  ine 

ADDR 

40 

ttdef ine 

RTRN 

41 

ttdef ine 

INDX 

4£ 

ttdef ine 

FNDC 

45 

ttdef ine 

STMT 

46 

ttdef ine 

DUMY 

47 

ttdef ine 

BREK 

48 

ttdef ine 

DFLT 

49 

ttdef ine 

INCR 

50 

ttdef ine 

DCRT 

51 

ttdef ine 

INCL 

5£ 

/*  integer  addition  */ 

/*  integer  subtraction  */ 

/♦  integer  multiply  */ 

/*  integer  division  */ 

/*  integer  modulus  ■*/ 

/*  label  declaration  */ 

/  *  Lincond  i  t  i  ona  1  j  urn p  * / 

/*  jump  if  true  */ 

/*  jump  if  false  */ 

/*  logic  expression  */ 

/*  constant  */ 

/*  array  identifier  ■*/ 

/*  variable  */ 

/*  unary  minus  ■*/ 

/*  unary  logic  not  */ 

/*  equal  i t y  •*/ 

/*  not  equal  */ 

/*  less  than  */ 

/*  greater  than  •*/ 

/*  less  than  or  equal  */ 
/*  greater  than  or  equal*/ 

/*  logic  and  */ 

/*  logic  or  */ 

/*  assignment  ■*/ 

/*  addition-assignment  */ 

/*  subtract  ion— ass i gn  */ 

/*  multiply—assignment  -*/ 

/*  division-assignment  ■*/ 

/*  modulus-assignment  ■*/ 

/*  function  call  */ 

/*  argument  ■*/ 

/*  explicit  label  */ 

/*  jump  toexp.  label  */ 

/*  case  statement  */ 

/*    temporary  variable  #  */ 

/*    switch  statement  ■*/ 

/*  pointer  */ 

/*  address  */ 

/*  return  */ 

/*  index  */ 

/*  function  declaration  •*/ 

/*  statement  •*/ 

/*    dummy  statement  ■*/ 

/*  break  statement  ■*/ 

/*  default  case  */ 

/*  increment  ■*/ 

/*  decrement  */ 

/*  increment,   later  */ 
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#def ine 

DCRL 

53 

#define 

NOOP 

54 

#def ine 

TEMP 

55 

#def ine 

CNVB 

56 

■ttdefine 

BTEM 

57 

#def ine 

FEND 

58 

ttdef ine 

MAIN 

59 

#def i  ne 

MEND 

60 

/*  decrement,  later  */ 

/*  no  operation        -  */ 

/*  temporary  variable  ■*/ 

/*  convert  to  boolean  ■*/ 

/*  boolean  temporary  */ 

/*  function  end  •*/ 

/*  main  function  */ 

/*  end  of  main  function  ■*/ 
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APPENDIX  F 


TEST  PROGRAMS  FOR  THE  TINY-C  COMPILER 


Program  1 


main ( ) 


int   Joe,  jimmy; 

Joe=5; 

j  i  mmy= 1 5 ; 

switch  (  Joe  *  5  ) 

•C 

case  1£  :  ++Joe; 

break ; 
default  :  joe~j immy+S7; 

break ; 
case  14  :  Joe=  Jimmy — ; 

break ; 
> 
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The  Code  for  the  Program  1 


codeseg  equ 
dataseg  equ 
org 
syml     ds 


»ym£     ds 

org 
jmp 


ma  1  n  : 


i  m  1  b  1  £  : 


i  m  1  b  1 3  : 


i  m  1  b  1  4 


i  m  1  b  1  iZi 


i  m  1  b  1  1 


(iZi:i2i) 

( 1  :0) 

dataseg 

1 

1 

codeseg 

ma  i  n 

■Cint,  5>,  r  (0:0) 

■C  int,  15>,  r(0s  1) 

r(0:0),r<0:£) 

r(0:0),r(0:£) 

r (0:0)  ,  syml 

r (0 : 1 ) , sym£ 

r  (0 :  £)  ,  sym3 

i  rn  1  b  1 0 

move 

move 

mov 

m  u  1 

move 

move 

move 

jmp 


move  sym 1 , r ( 0 : 0 ) 

add  -Cint,  1>,  r  (0:0)  ,  r  (0:  1) 

move  r ( 0 : 1 )  ,  sym 1 

J  nip  i  rn  1  b  1  1 

move  •{  int ,  £7>,  r  (0  :  0) 

move  sym£, r (0: 1) 

add  r  (0:  1)  ,  r  (0:iZi) 

move  r (0:0), syml 

j  m  p  i  m  1  b  1 1 

move  sym£, r ( 0 : 0 ) 

sub  -C  int,  1  >,  r  (iZi:i3)  ,  r  (0:  1) 

move  r (0:0), syml 

move  r ( 0 : 1 ) , sym£ 

j  nip  i  m  1  b  1 1 

move  syrn3,  r(0:0) 

move  -Cint,l£>,r(0:l) 

if  r (0:0) ==r (0: 1 )  ,  implbl£ 

move  -C  int ,  14>,  r  (0:  £) 

if  r (0:0) ==r (0:£)  ,  implbl4 

jmp  i  m  p 1 b 1 3 

stop 
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Program    cl. 


main  (  ) 
■C 


irit       joe,     jirnrny; 

joe=3; 

j  i  rnrny= j  oe*37  ; 

if     (    joe    >     37    &&    jirnmy<  =  joe    &&    jirnrny    ) 

j  i  rnmy=  1 8  ; 
> 
else 

j  irnmy=i=:7 ; 

j  oe= j  i  rnmy+£5  ; 


102 


;  he  Code  for  the  t-roqram 


ma  1  n 


codeseg  equ 
dataseg  equ 
org 
syrnl     ds 
syrn2     ds 

org 
jmp 

move 

move 

m  u  1 

move 

if 

move 

J  rip 

move 

if 

move 
J  mp 

move 

and 
if 

move 
jmp 

move 

and 

move 

move 

if 

move 

move 

jmp 

move 
move 

move 
move 
add 
stop 


blbliZi: 
blbl  1  : 

blbl2: 
blbl3: 


blbl4 

blblS 


l  m  1  b  1  0  : 


imlbl 1 : 


(0:0) 

(  1  :0) 

dataseg 

1 
1 

codeseg 
main 

-C  int,  3>,  r  (12:0) 
-Cint,  37},  r(0:  1 ) 
r<0:0),r(0:l) 

-Cint,  37},  r  (0:2) 

r  (iZi:iZD  >r  (0:2)  ,  blbliZi 

-Cbool ,  false},  r  (\&:3) 

blbll 

•C boo 1 , true), r  ( 0  :  3 ) 

r  (0:  1)  <=r  (0:0)  ,  bib  IE: 
Cbool,  false >, r (0:4) 
blbl3 

{  boo  1 ,  true},  r  ( 0  :  4 ) 

r(0:3),r(0:4) 

r  (0:  1)==-Cint,  0>,  blbl  4 

-C  bool,  true},  r  (0:5) 

blblS 

{bool,  false}, r (0:5) 

r  (  0  :  4  )  ,  r  (  0  :  5 ) 

r (0 :0) , syrnl 

r  (0 :  1  )  ,  syrn2 

r (0:5) ==< bool,  false},  imlbl0 

tint,  18}, r (0:0) 

r  (0:0)  ,  syrn£ 

l  rn  1  b  1  1 

tint, 27}, r (0:0) 

r (0:0) , sym2 

■C  int ,  25},  r  (0:0) 
sym2, r (0 :  1  ) 
r  ( 0  :  1  )  ,  r  ( 0  :  0 ) 
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Program    3. 

funct  i  on  ( j  oe,  j  i  rnrny ) 
int     joe,     j immy ; 

■C 


do 

joe 

wh lie     (    joe 

— j  immy ; 


:    j  i  rnrny ++ ; 

==    3)  ; 


ma in() 
•C 


int     joe,     j  immy ; 


j  immy =5 ; 


joe    =    j  immy — ; 
wh  i le     (    joe    ==    3)  ; 

f  unct  i  on  (  j  i  rnrny,  j  oe )  ; 

++ j  immy ; 
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The  Code  for  the  Program  3. 


codeseg 

equ 

dataseg 

equ 

org 

syrnl 

ds 

sym£ 

ds 

sym4 

ds 

syrn5 

ds 

org 

J  nip 

funct ion : 

pop 

pop 

move 

move 

i  rn  1  b  1 0  : 

move 

add 

move 

if 

move 

j  ump 

blbliZi: 

move 

blbll  : 

move 

move 

if 

i  m  1  b  1  1  : 

move 

sub 

push 

rts 

(iZi 

:iZD 

(1 

:0) 

da 

tase 

g 

1 

1 

1 

1 

CO 

dese 

g 

main 

s(0)  ,  r  (0:0) 
s  ( 0 )  ,  r  ( 0  :  1  ) 
r  (0:0)  ,  syrnl 
r (0 : 1 ) , sym£ 

symiE:,  r  (0  :  0) 

■C  int,  1  >,  r  (0:0)  ,  r  (0:  1) 

■C  int ,  3>,  r  (0:  £) 

r ( 0 : 0 ) ==r ( 0 : £ ) , b 1 b 1 0 

■C  bool ,  false),  r  (0:3) 

blbll 

■C  bool ,  true),  r  (0  :  3) 

r  (0:0)  ,  syrnl 
r (0 : 1 ) , sym£ 
r  ( 0  :  3 )  ==-C  boo  1 ,  t  r  ue  } ,  i  m  1  b  1 0 

syrn£,  r  ( 0  :  0) 

-C  int,  1>, r (0:0) , r (0: 1) 

-Cint,  1>,  s(0) 

s(l) 


ma  l  n : 

move 

-Cint,  5>,  r  (0:iZD 

move 

r (0:0) , sym5 

move 

r  (0 :  1 )  ,  symiE: 

i  m  1  b  1 2  s 

move 

sym5, r (0:0) 

sub 

<  int,  1>, r (0:0) , r (0: 1) 

move 

■C  int,  3>,  r  (0:2) 

if 

r  (0:0)==r  (0:£)  ,  bible: 

move 

-Cbool,  false},  r  (0:3) 

j  ump 

blbl3 

blbl£: 

move 

-C  boo  1 ,  true},  r  ( 0  :  3 ) 

10; 


blbl3: 


i  rn  1  b  1 3 


mo ve  r  (  iZi  :  0 )  ,  sy  rn4 

move  r ( 0  s 1 ) , sym5 

if  r (0:3)  ==<  bool ,  true),  irnlbli 

move  sy  rn4 ,  r  ( 0  :  0 ) 

push  r(0:0),s(0) 

move  syrn5,  r  (0 s  1 ) 

push  r  (0:  1 )  ,  s  (0) 

jsr  f uncal 1 , s ( 1 ) 

pop  s (0) , r (0 : £) 

add  -Cint,  1  >,  r  (0:  1)  ,  r  (0:3) 

stop 
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